Difference between revisions of "GCube Maven BOMs"

Revision as of 19:21, 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 third party dependencies or even other teams 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 imports it.

The GHN Maven BOM

In the case of gCube, each gCube service is deployed and runs in an old fashion 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 inform a gCube developer that there might be clashes once the service is deployed in a container, a Maven BOM for the GHN has been developed.

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 should 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) :

This warning can be ignored of course but it's highly recommended not to include a version different from the one managed by the BOM. In the case a new version of an artifact is needed ( especially third-party) so the override of the managed version is not evitable, accurate test must be conducted in order to understand if the new version of the artifact can be compatibly installed on the GHN container.

2) Each service transitive dependency are going to be also managed by the one specified in the BOM. This means that if a dependency of the service depends on an artifact which is present on the BOM, the version specified on the BOM is going to be used.

It's easy to check this behavior by looking at the Dependency Hierarchy section available in Eclipse: