I created a library in maven that can be extended by implementing some interfaces. To test the default implementation I have written some hamcrest matchers that currently live in src/test/java.
However, I think they might be useful for users of the library if they want to test their customization.
So how can I make them available? Moving them to src/main would require to make hamcrest a runtime dependency and I don't want that.
There is a way to create a test jar and install it into the repository using the command 'mvn jar:test-jar'. This jar can then be referenced by other projects using the test-jar modifier in the dependency block.
If you want to have this jar built and installed as part of your your normal 'mvn install' build add the following plugin config to your pom:
From http://maven.apache.org/guides/mini/guide-attached-tests.html
<project>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Then other projects can reference the test jar as follows:
<dependency>
<groupId>com.myco.app</groupId>
<artifactId>foo</artifactId>
<version>1.0-SNAPSHOT</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>
As you said, move it to src/main in a new project. Let that project only be used in a test dependency and you don't pollute your module's classpath.
It sounds like you need to move them to their own project and release it. From there you can determine in the original project what scope you'd like.
Related
I use maven to build a multi module project. My module 2 depends on Module 1 src at compile scope and module 1 tests in test scope.
Module 2 -
<dependency>
<groupId>blah</groupId>
<artifactId>MODULE1</artifactId>
<version>blah</version>
<classifier>tests</classifier>
<scope>test</scope>
</dependency>
This works fine. Say my module 3 depends on Module1 src and tests at compile time.
Module 3 -
<dependency>
<groupId>blah</groupId>
<artifactId>MODULE1</artifactId>
<version>blah</version>
<classifier>tests</classifier>
<scope>compile</scope>
</dependency>
When I run mvn clean install, my build runs till module 3, fails at module 3 as it couldn't resolve the module 1 test dependency. Then I do a mvn install on module 3 alone, go back and run mvn install on my parent pom to make it build. How can I fix this?
I have a doubt about what you are trying to do but but I'll assume you want to reuse the tests that you have created for a project (module1) in another. As explained in the note at the bottom of the Guide to using attached tests:
Note that previous editions of this guide suggested to use <classifier>tests</classifier> instead of <type>test-jar</type>. While this currently works for some cases, it does not properly work during a reactor build of the test JAR module and any consumer if a lifecycle phase prior to install is invoked. In such a scenario, Maven will not resolve the test JAR from the output of the reactor build but from the local/remote repository. Apparently, the JAR from the repositories could be outdated or completely missing, causing a build failure (cf. MNG-2045).
So, first, to package up compiled tests in a JAR and deploy them for general reuse, configure the maven-jar-plugin as follows:
<project>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Then, install/deploy the test JAR artifact as usual (using mvn install or mvn deploy).
Finally, to use the test JAR, you should specify a dependency with a specified type of test-jar:
<project>
...
<dependencies>
<dependency>
<groupId>com.myco.app</groupId>
<artifactId>foo</artifactId>
<version>1.0-SNAPSHOT</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>
</dependencies>
...
</project>
Regarding to my comment to Pascals question i think i have found a stuitable answer :
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
<phase>test-compile</phase>
</execution>
</executions>
<configuration>
<outputDirectory>${basedir}\target</outputDirectory>
</configuration>
</plugin>
</plugins>
The main difference here as you see here is the <phase> tag.
I will create the test-jar and it will be available in the compile phase of the tests and not only after the package phase.
Works for me.
Let's say that I put the following plugin in my pom.xml file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>make-a-jar</id>
<phase>compile</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<finalName>my-artifact-name</finalName>
</configuration>
</execution>
</executions>
</plugin>
and I run "mvn clean install".
Maven creates two jar files in target library.
The first jar file compiles the source files and the second jar compiles the test files. Both of these jar will have the same artifact name.
If I want to use the jar of source code as a dependency in another project, I can put the following dependency in the other project:
<dependency>
<groupId>groupId</groupId>
<artifactId>my-artifact-name</artifactId>
<scope>system</scope>
<type>jar</type>
<systemPath>${basedir}/lib/my-artifact-name.jar</systemPath>
</dependency>
So far so good.
A problem arises if I also want to add a dependency for the test files. In this case I will have two dependencies with the same groupId and artifactId and different systemPath. Maven will not read two dependencies with same groupId and artifactId. Only one of them will be read.
One solution that I can think of is to make Maven to give a different artifact name for test.
Do you know how to do it?
My general answer to that would be:
The tests in src/test/java are only for running them during the build. They need not be put into any jar.
If you need classes as helper classes for your tests, you can create a separate jar which contains these classes. This can then be used as test dependency.
In any case, try to avoid <systemPath>. If you build your project with mvn clean install on your computer, you can reference the resulting jar with a dependency like
<dependency>
<groupId>groupId</groupId>
<artifactId>my-artifact-name</artifactId>
<version>1.2.3</version>
</dependency>
anywhere on the same account/computer without giving a <systemPath>.
I need to access one bean class from war project into my another war project. The bean class is exists in MyProject. I wrote pom of another project called NewProject as follows.
<groupId>MyProject</groupId>
<artifactId>MyProject</artifactId>
<version>1</version>
</parent>
<artifactId>MyProject</artifactId>
<packaging>war</packaging>
Is it possible to add war dependency in another war project?
If you configure the maven-war-plugin with the following attribute:
<attachClasses>true</attachClasses>
you would get an supplemental artifact with the following coordinates:
<dependency>
<groupId>myGroup</groupId>
<artifactId>myArtifact</artifactId>
<version>myVersion</myVersion>
<classifier>classes</classifier>
</dependency>
which contains all classes within your war project which can be used as dependency which is a jar file which will solve your problem.
In your war project
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<attachClasses>true</attachClasses>
</configuration></plugin>
It creates a classes artifact which you can use in the required project
<dependency>
<groupId>your-group-id</groupId>
<artifactId>your-artifact-id</artifactId>
<version>your-version</version>
<classifier>classes</classifier>
refer maven war plugin
hope it helps...
Dependencies work using jars, and you would normally define a common dependency in a .jar file that can be accessed by both .wars. That's not Maven-specific, but how dependencies in Java work. The internal structure of a .war is different from a .jar in terms of how the classes are laid out.
Consequently in Maven, I would expect to define a .jar project, and then two .war projects both depending on the initial project.
You are better off IMHO creating a jar with your war classes that are needed in your project.
And then just add the dependency to your project configuration (classifier classes).
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>classes</id>
<phase>compile</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>classes</classifier>
</configuration>
</execution>
</executions>
</plugin>
Move your re-usable classes into a separate module. This will help:
Test things quicker.
Use the code as a dependency in other projects.
Alternatively, you could produce a classes only jar by using the maven-jar-plugin and producing a classifier-based artifact. However, I think my suggestion is better in the fact that it give you a clear separation of the code and forces you to organize your code better.
Good time!
Our team uses Maven. One of the project modules has a plugin (maven-jibx-plugin) that requires (for our use-case) a dependency on a proprietary jar:
<plugin>
<groupId>org.jibx</groupId>
<artifactId>jibx-maven-plugin</artifactId>
<version>${jibx.version}</version>
<executions>
<execution>
<id>main-schemas</id>
<phase>generate-sources</phase>
<goals>
<goal>schema-codegen</goal>
</goals>
<configuration>
<schemaLocation>
...
</schemaLocation>
<includeSchemas>
...
</includeSchemas>
<customizations>
<customization>${basedir}/src/main/resources/customizations/customization.xml
</customization>
</customizations>
<verbose>true</verbose>
</configuration>
</execution>
<execution>
<id>bind</id>
<phase>process-classes</phase>
<goals>
<goal>bind</goal>
</goals>
<configuration>
<schemaBindingDirectory>
${basedir}/src/main/resources/bindings
</schemaBindingDirectory>
<includeSchemaBindings>
<includeSchemaBinding>*.xml</includeSchemaBinding>
</includeSchemaBindings>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>${project.parent.groupId}</groupId>
<artifactId>proprietary-jar</artifactId>
<version>${project.parent.version}</version>
</dependency>
</dependencies>
</plugin>
The problem is when we build the project locally (and even from a command line on the remote machine where jenkins is istalled), everything builds successfully, but when our jenkins instance tries to build it - the build fails with such a message: "Unable to find class 'class-name-from-the-proprietary-jar'". This problem occurred loccally before we added the plugin dependency..
Seems like there is some feature of jenkins maven plugin that do no resolve the plugin dependencies or may be there are some well-known feature of the jenkins maven plugin classloading (JiBX loads proprietary classes with such a construct: SchemaRootBase.class.getClassLoader().loadClass(cname) So that specifing the dependency for the plugin should provide a knowledge for it about the required classes)... Can somebody, please, suggest the workaround?
UPDATE:
it turned out that the jenkins instance's JAVA_HOME variable is set to /usr/java/jdk1.7.0_25, but in my maven-compiler-plugin I have <target>1.6</target>. Could it be that the problem is in the 1.7 java version?
Well, finally I've found an answer! The problem is not actually in Jenkins, but rather in Maven itself.
ATTENTION: the undergoing information is tested only for Maven 2.
It turned out that when you have a multimodule project and several modules use the same plugin (with different dependencies), Maven would get dependencies set for the first plugin (I mean that the plugin is located in the first module, that Maven builds, with this plugin) and use them for other plugins not overriding the dependencies by the local values.
To clarify this lets have an example. Say there are two modules in the maven build - A and B:
<modules>
<module>A</module>
<module>B</module>
</modules>
and the module A has such the code in the pom file:
<plugin>
<dependencies>
<dependency>
<groupId>com.c</groupId>
<artifactId>D-module</artifactId>
<version>1</version>
</dependency>
</dependencies>
<groupId>org.jibx</groupId>
<artifactId>jibx-maven-plugin</artifactId>
<version>${jibx.version}</version>
</plugin>
and the module B has such the code in the pom file:
<plugin>
<dependencies>
<dependency>
<groupId>com.c</groupId>
<artifactId>F-module</artifactId>
<version>1</version>
</dependency>
</dependencies>
<groupId>org.jibx</groupId>
<artifactId>jibx-maven-plugin</artifactId>
<version>${jibx.version}</version>
</plugin>
It turns out that when Maven builds the module B it will use the D-module dependency even though you have specified the F-module dependency.
In our project we made such a workaround: we moved the plugin declaration to the parent pom in a pluginManagement section and declared the D-module and F-module dependencies for the plugin (also removed these dependencies from the local modules). Ok, the code is rather ugly (having child dependencies in the parent pom file), but this works!
If somebody shared this issue and managed to overcome it, please, advice the solution.
Try mvn clean install in your workspace
Then you should have the same error every where. Also try and use the same command line Jenkins is using (if any)
I have a project that uses "system" scope to specify a jar file included in my project's WEB-INF/lib dir. This artifact is not in any of the maven repositories, so I must include it as part of my project. I do so with the following:
<dependency>
<groupId>com.example</groupId>
<artifactId>MySpecialLib</artifactId>
<version>1.2</version>
<scope>system</scope>
<systemPath>${basedir}/src/main/webapp/WEB-INF/lib/MySpecialLib-1.2.jar</systemPath>
</dependency>
This has worked great for most things.
But now I'm trying to run some code on the command line (outside of my webapp, via a main() method I have added) and mvn exec:java can't resolve code in MySpecialLib because it's not included in the "runtime" classpath.
How can I either:
add MySpecialLib to the runtime classpath
or
tell mvn exec:java to also use the system classpath ?
I've tried mvn exec:java -Dexec.classpathScope=system, but that leaves off everything that's on runtime.
Use 'compile' scope to run maven exec plugin - mvn exec:java -Dexec.classpathScope=compile. This will include system-scoped dependencies.
As E.G. pointed out, the solution is to use the compile scope when running exec.
On each invocation:
mvn exec:java -Dexec.classpathScope=compile
or directly in the exec-plugin-configuration:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
...
<configuration>
<classpathScope>compile</classpathScope>
</configuration>
</plugin>
Interesting to know that classpathScope=system drops runtime dependencies. I found that by including it as a plugin in the pom.xml works as an alternative. Could you please try and let me know if it works for you too?
So I added a system level dependency to commons-collection as an example like you have for your artifact:-
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.0</version>
<scope>system</scope>
<systemPath>C:\\<some_path>\\commons-collections-3.0.jar</systemPath>
</dependency>
Then in the <build> tag I have the exec-maven-plugin plugin to be executed in the install phase:-
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>java</goal>
</goals>
<configuration>
<mainClass>com.stackoverflow.test.App</mainClass>
</configuration>
</execution>
</executions>
</plugin>
Then I ran mvn install. I also made sure com.stackoverflow.test.App class has some code that invokes a class from commons-collections-3.0.
Hope this helps.
The right answer is to use the maven-install-plugin and Put The Jar Into Your Local Repo. Or, better yet, run nexus or artifactory and use the deploy plugin to put the jar into there. System classpath is just a world of hurt.