Difference between revisions of "GCube Maven BOMs"

From Gcube Wiki
Jump to: navigation, search
(the GHN Maven BOM)
(the GHN Maven BOM)
Line 47: Line 47:
  
 
this way the  dependency version are managed by a single component and they are always aligned to the latest version available. In case the developer is going to specify a version for a managed dependency it will be highlighted directly by the IDE ( i.e. Ecplise) :
 
this way the  dependency version are managed by a single component and they are always aligned to the latest version available. In case the developer is going to specify a version for a managed dependency it will be highlighted directly by the IDE ( i.e. Ecplise) :
 +
 +
[[FIle:Schermata_2013-01-31_alle_17.48.30.png]]

Revision as of 17:52, 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 :

<dependencyManagement>
    <dependencies>
     ...
       <dependency>
           <groupId>org.gcube.distribution</groupId>
           <artifactId>maven-bom</artifactId>
           <version>LATEST</version>
           <type>pom</type>
           <scope>import</scope>		
      </dependency>
    ...
   </dependencies>
</dependencyManagement>

The scope import implies that the pom declarations within the maven BOM are imported in the service parent pom and its submodules. In particular this means that all dependencies declared in the maven submodules are managed by the ones declared in the BOM :

1) Each dependency declared in a module which is also contained in the BOM can be specified withut the version parameter, i.e.:

    <dependency>
        <groupId>org.gcube.core</groupId>
        <artifactId>gcf</artifactId>
     </dependency>

this way the dependency version are managed by a single component and they are always aligned to the latest version available. In case the developer is going to specify a version for a managed dependency it will be highlighted directly by the IDE ( i.e. Ecplise) :

Schermata 2013-01-31 alle 17.48.30.png