|
|
| (2 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | This sections is meant to provide operative instructions about most relevant aspects of creation of ETICS configurations for Maven-based components.
| + | [[Category: Developer's Guide]] |
| − | | + | moved to [[ETICS#How_to_create_ETICS_configurations_for_gCube_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. <code>mvn deploy</code>). 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 <code>${prefix}</code>''' 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 <code>${prefix}</code> 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:
| + | |
| − | | + | |
| − | [[Image:maven-component-configuration.png|600px|center|Example of maven-component's build commands]] | + | |
| − | | + | |
| − | '''Note''': please note that configuration's commands (mainly <code>install</code> 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 [[Developing_gCube_Maven_Components#Services| 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 <code>mvn deploy -N</code> 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 <code>mvn deploy -pl exampleservice-stubs</code> is invoked to build and compile '''only''' the stubs module.
| + | |
| − | [[Image:Mvn_services_stubs.png|600px|center|Example of stubs build commands]] | + | |
| − | | + | |
| − | | + | |
| − | 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 <code>mvn deploy -pl exampleservice-service</code> it is needed to also build the stubs <code>mvn install -pl exampleservice-stubs</code>. 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.
| + | |
| − | [[Image:Mvn_services_service.png|600px|center|Example of service build commands]]
| + | |
| − | | + | |
| − | == Dependencies ==
| + | |
| − | The configuration must directly or indirectly '''depend on the ETICS configurations of all gCube components that are specified in the POM''', including ''maven-parent''. 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:
| + | |
| − | [[Image:Maven-deps.png|700px|center|Example of maven-component's dependency set]]
| + | |
| − | | + | |
| − | == Environment ==
| + | |
| − | Unlike Ant-based components, Maven components do not use the <code>CLASSPATH</code> 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:
| + | |
| − | <pre>
| + | |
| − | CLASSPATH: ${moduleDir}/target/<artifactid>-${version}-[SNAPSHOT|${maven.system-version}].jar
| + | |
| − | </pre>
| + | |
| − | 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
| + | |
| − | * <code>SNAPSHOT</code> must be added only if you are setting up a configuration for org.gcube.HEAD otherwise
| + | |
| − | * you should use the <code>${maven.system-version}</code> property
| + | |
| − | * <code>${moduleDir}</code> and <code>${version}</code> are ETICS properties and will be resolved by ETICS itself
| + | |
| − | | + | |
| − | Valid examples of CLASSPATH:
| + | |
| − | <pre>
| + | |
| − | 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
| + | |
| − | ...
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | '''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/<span style="background-color:#E6E6FA">target/catalogue-of-life-spd-plugin-1.0.0-2.12.0.jar</span> to...''"
| + | |
