Testing with Maven and MyContainer
From Gcube Wiki
Revision as of 14:04, 11 December 2012 by Fabio.simeoni (Talk | contribs)
It's easy to configure Maven components to use my-container
for in-container testing of services and service clients.
- Specify dependencies to
my-container
's runtime and and distribution:
<!-- runtime --> <dependency> <groupId>org.gcube.tools</groupId> <artifactId>my-container</artifactId> <version>[X.0.0-SNAPSHOT,X+1.0.0-SNAPSHOT)</version> <scope>test</scope> </dependency> <!-- distro --> <dependency> <groupId>org.gcube.tools</groupId> <artifactId>my-container</artifactId> <version>[X.0.0-SNAPSHOT,X+1.0.0-SNAPSHOT)</version> <type>tar.gz</type> <classifier>distro</classifier> <scope>test</scope> </dependency>
- note: as with any other gCube component, we prefer to depend on any version within a "major" range, where we expect interface compatibility between versions. Using ranges gives us early integration feedback and transparent implementation updates. We do not need to fear for build reproducibility as, at integration time, the range will be automatically replaced with the version of
my-container
with which we are integrating.
- Configure the [maven-dependency-plugin Maven Dependency Plugin] to download and unpack the dependency to the distribution of
my-container
:
<plugin> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <id>install-my-container</id> <phase>generate-test-resources</phase><!-- runs before tests --> <configuration> <includeArtifactIds>my-container</includeArtifactIds> <includeTypes>tar.gz</includeTypes> <overWriteIfNewer>false</overWriteIfNewer> <outputDirectory>${project.basedir}</outputDirectory> <markersDirectory>${project.basedir}</markersDirectory> </configuration> <goals> <goal>unpack-dependencies</goal> </goals> </execution> </executions> </plugin>
- Here we perform the installation in the project's root directory, which is where
my-container
's runtime will find it by default. We also choose thegenerate-test-resources
phase of the build lifecycle as we see the distribution ofmy-container
as a test resource. Finally, note that we use theunpack-dependencies<code> goal of the plugin, pointing to the explicit dependency declared in the previous step.