Difference between revisions of "GCube Maven BOMs"
Andrea.manzi (Talk | contribs) (→What is a BOM) |
Andrea.manzi (Talk | contribs) (→the GHN Maven BOM) |
||
| Line 9: | Line 9: | ||
== the GHN Maven BOM == | == the GHN Maven BOM == | ||
| − | In the case of gCube, | + | In the case of gCube, each gCube service is deployed and runs in an ''old fashioned'' container based on globus WS-Core 4.0, which unfortunately does not implement separate classloaders for each deployed component as for the latest web service containers ( like OGSA or tomcat) . |
| − | Given that we have to deal with a flat classloader schema which leads | + | Given that we have to deal with a flat classloader schema which leads very easily to artifact clashes, especially clashes of different version of the same artifact. Given that |
Revision as of 16:31, 31 January 2013
What is a BOM
When dealing with large projects like in the case of gCube, it's fondamental to introduce mechanism in order to mitigate the anarchy of developers in using thrid party dependencies or even other developers artifacts versions.
As described in the maven documentation [[1]] there is a standard way to define the base artifacts of a project by implementing a BOM ( BIll of Materials)
The Maven BOM is a pom only component which fixed the dependencies and base versions of a component which import it.
the GHN Maven BOM
In the case of gCube, each gCube service is deployed and runs in an old fashioned container based on globus WS-Core 4.0, which unfortunately does not implement separate classloaders for each deployed component as for the latest web service containers ( like OGSA or tomcat) .
Given that we have to deal with a flat classloader schema which leads very easily to artifact clashes, especially clashes of different version of the same artifact. Given that
