Difference between revisions of "Testing with Maven and MyContainer"

From Gcube Wiki
Jump to: navigation, search
(Created page with 'It's easy to configure Maven components to use <code>my-container</code> for in-container testing of services and service clients. # Specify dependencies to <code>my-container</…')
 
Line 1: Line 1:
 
It's easy to configure Maven components to use <code>my-container</code> for in-container testing of services and service clients.
 
It's easy to configure Maven components to use <code>my-container</code> for in-container testing of services and service clients.
  
# Specify dependencies to <code>my-container</code>'s runtime and and distribution:
+
* Specify dependencies to <code>my-container</code>'s runtime and and distribution:
  
 
<source lang="xml">
 
<source lang="xml">
Line 25: Line 25:
 
</source>
 
</source>
  
: As with any other gCube component, we prefer to depend on any version within a major range, where we expect interface compatibility. 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 <code>my-container</code> with which we are integrating.
+
: '''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 <code>my-container</code> with which we are integrating.
  
# Configure the [maven-dependency-plugin Maven Dependency Plugin] to download and install the dependency:
+
* Configure the [maven-dependency-plugin Maven Dependency Plugin] to download and unpack the dependency to the distribution of <code>my-container</code>:
  
 
<source lang="xml">
 
<source lang="xml">
Line 53: Line 53:
 
</source>
 
</source>
  
: Here we perform the installation in the project's root directory, which is where <code>my-container</code> runtime will find it by default. We also choose the <code>generate-test-resources</code> phase of the build lifecycle as we see the distribution as a test resource.
+
: Here we perform the installation in the project's root directory, which is where <code>my-container</code>'s runtime will find it by default. We also choose the <code>generate-test-resources</code> phase of the build lifecycle as we see the distribution of <code>my-container</code> as a test resource. Finally, note that we use the <code>unpack-dependencies<code> goal of the plugin, pointing to the explicit dependency declared in the previous step.

Revision as of 14:04, 11 December 2012

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