ETICS configurations for gCube Maven Components

This sections is meant to provide operative instructions about most relevant aspects of creation of ETICS configurations for Maven-based components.

Versioning

Version field of the ETICS configuration must match the version specified for the Maven project in the pom.xml, excepting for the "-SNAPSHOT" postfix. The match will be checked during the invocation of mvn to guarantee that ETICS versions are always in sync with Maven versions.

Build Commands

• the compile target of their Build Commands must invoke Maven to build the components up to the deploy phase (e.g. mvn deploy). This allows the deployment of components into Maven repositories directly from ETICS builds

• the install target of their Build Commands must copy the gCube profile of the component in the ${prefix} directory. This allows the registration of the profile with the Software Gateway when the component is released. It remains a good practice to copy also the outcome of the compilation (usually jar files) in ${prefix} in order to include them in packages generated by ETICS

Sample build commands for a maven-based component should look like the one in the picture below:

Note: please note that configuration's commands (mainly install target) could change slightly depending on the actual project structure.

Build Commands for gCube Services

gCube services components are usually multi-modules maven projects (see gCyve Service development guide for more information) containing a module for the stubs, one for the service and optionally one for test-suites. In ETICS a service must be modelled with one ETICS component for each Maven project's module.

For each ETICS component, build commands should contains commands to deploy only the correspondent Maven module, and, if needed, compile the other modules needed by the first.

Picture below shows the typical build commands for the stubs component. First the mvn deploy -N is invoked to deploy the project's parent pom. If not executed, stubs' compilation will fail because parent's pom will not be resolved. Then the mvn deploy -pl exampleservice-stubs is invoked to build and compile only the stubs module.

Finally, picture below shows the typical build commands for the service component. Since the service module of a gCube service needs the stubs to be compiled locally in order to generate the gar archive, before execute the mvn deploy -pl exampleservice-service it is needed to also build the stubs mvn install -pl exampleservice-stubs. Note that it is not needed to invoke target deploy for stubs, since they are deployed already by the stubs ETICS' component. The parent's pom will already exist in the local repository (deployed by the stubs' component) and, thereofore, it is not needed to compile it again.

Dependencies

The configuration must directly or indirectly depend on the ETICS configurations of all gCube components that are specified in the POM, including maven-builder. This guarantees that at build-time all dependencies requested by the pom.xml have been already compiled and installed on the Maven's local reposiotry.

Dependencies on third-party components available in Maven Central (or other Maven repository specified in the POM) do not need to be configured in ETICS (i.e. Maven repositories replace ETICS externals).

All dependencies must be declared of type dynamic and the actual version will be resolved at project level.

Example of dependencies for a Maven component:

Environment

Unlike Ant-based components, Maven components do not use the CLASSPATH variable for compile-time dependency resolution, but rely on the Maven local repository. This means that the Environment section of Maven component's configurations will be empty (unless other environment variables has to be set for other purposes).

There exist an exception, though. If the component's artifact is meant to be used as compile-time dependency by others Ant-based components, the artifact produced by the Maven build needs to be exported in the CLASSPATH to allows the Ant-based component to find it. Only in this case the Environment section will contain an entry to add to CLASSPATH the artifact produced. It is suggested to use following convention:

CLASSPATH: ${moduleDir}/target/<artifactid>-${version}-[SNAPSHOT|${maven.system-version}].jar

where:

• <artifactId> must be replaced with the name of the artifact produced by Maven compilation. By default it is the same of <artifactId> value in the pom
• SNAPSHOT must be added only if you are setting up a configuration for org.gcube.HEAD otherwise
• you should use the ${maven.system-version} property
• ${moduleDir} and ${version} are ETICS properties and will be resolved by ETICS itself

Valid examples of CLASSPATH:

CLASSPATH: ${moduleDir}/target/home-library-${version}-${maven.system-version}.jar
CLASSPATH: ${moduleDir}/target/home-library-${version}-SNAPSHOT.jar
CLASSPATH: ${moduleDir}/SoftwareGateway-stubs/target/softwaregateway-stubs-${version}-${maven.system-version}.jar
CLASSPATH: ${moduleDir}/SoftwareGateway-stubs/target/softwaregateway-stubs-${version}-SNAPSHOT.jar		
...

Tip: you can easily find exactly which artifact is created during an ETICS build by searching in the build report of the component for the line "Installing /home/gbuilder/catalogueoflife-spd-plugin/target/catalogue-of-life-spd-plugin-1.0.0-2.12.0.jar to..."