Difference between revisions of "Testing with Maven and MyContainer"

Latest revision as of 10:37, 25 July 2013

It's easy to configure Maven components to use my-container for in-container testing of services and service clients.

• step one: 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.

• step two: configure the 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 the generate-test-resources phase of the build lifecycle as we see the distribution of my-container as a test resource. Finally, we use the unpack-dependencies goal of the plugin, pointing to the explicit dependency declared in the previous step.

note: the plugin configuration above requires that a special marker file is created alongside the distribution of my-container above. The marker file avoids that the distribution is re-downloaded only if there is a new version available, but should otherwise excluded from version control.

note: the Maven Dependency plugin includes an unpack goal, which can be used to a similar effect. The unpack goal, however, specifies the dependency on the distribution of my-container inside its configuration, instead of pointing to an explicit project dependency. For this reason, it: a) does not work with version ranges, and b) it is not rewritten to a concrete version of my-container at integration time. For these reasons, the use of the unpack goal is now strongly discouraged and will break the system build as new versions of my-container are made available for integration.