Difference between revisions of "GCube Maven BOMs"

From Gcube Wiki
Jump to: navigation, search
(the GHN Maven BOM)
(the GHN Maven BOM)
Line 9: Line 9:
 
== the GHN Maven BOM ==
 
== 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) .
+
In the case of gCube,  each gCube service is deployed and runs in an ''old fashioned'' container (GHN) 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
+
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. In order to avoid any possible clash or at least informe a gCube developer that there might be clashes once the service is deployed in a container, a Maven BOM for the GHN.
 +
 
 +
The BOM contains all the possible libraries that are contained in a standard GHN distribution ( there will be a secure version soon), specifying the version of the third party libraries and open ranges for the gCube one ( in order to have the latest version available).
 +
 
 +
The maven bom component is available on the gCube SVN trunk at [[https://svn.research-infrastructures.eu/d4science/gcube/trunk/distributions/maven-bom/]] and from the gCube maven repo ..
 +
 
 +
Every gCube Service that adopt Maven should include the maven BOM in its parent module pom. In particular it should include the BOM in the dependencies management section :

Revision as of 17:25, 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 (GHN) 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. In order to avoid any possible clash or at least informe a gCube developer that there might be clashes once the service is deployed in a container, a Maven BOM for the GHN.

The BOM contains all the possible libraries that are contained in a standard GHN distribution ( there will be a secure version soon), specifying the version of the third party libraries and open ranges for the gCube one ( in order to have the latest version available).

The maven bom component is available on the gCube SVN trunk at [[2]] and from the gCube maven repo ..

Every gCube Service that adopt Maven should include the maven BOM in its parent module pom. In particular it should include the BOM in the dependencies management section :