I'm working on an Eclipse RCP + Maven project for the first time and I want to run some unit tests on my bundles with JUnit. It seems that the most recommended approach is to create a bundle fragment and use something like Tycho plugin to resolve dependencies. However, when I run mvn clean verify in my master pom, it should run the tests and deploy my application, but I'm get the following error instead:
[ERROR] Cannot resolve project dependencies:
[ERROR] You requested to install 'myproject.app.feature.feature.group 1.0.0' but it could not be found
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.21.0:test (default-test) on project myproject.app.viewmanager-test: Execution default-test of goal org.eclipse.tycho:tycho-surefire-plugin:0.21.0:test failed: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from tycho-extra-1408913392535 0.0.0.1408913392535 to myproject.app.feature.feature.group 1.0.0.; Unable to satisfy dependency from tycho-1408913392552 0.0.0.1408913392552 to myproject.app.feature.feature.group 1.0.0.; No solution found because the problem is unsatisfiable.] -> [Help 1]
I understand that Maven is failing to find 'myproject.app.feature.feature.group 1.0.0' but I don't know where it is getting this from because it seems that the name is wrong.
It might be worth to say that when I run the unit test inside Eclipse (not with Maven) it works.
This is the Tycho configuration in my test fragment:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-surefire-plugin</artifactId>
<version>${tycho-version}</version>
<configuration>
<useUIHarness>true</useUIHarness>
<dependencies>
<dependency>
<type>eclipse-feature</type>
<artifactId>myproject.app.feature</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</configuration>
</plugin>
As suggested here, I'm adding the feature as a dependency because my test fragment requires some other bundles besides its host, so I was expecting this to work.
Any tips? The most similar issue I have found is this one, but both solutions didn't work for me.
Starting with Tycho 0.21.0, there is only limited support for declaring dependencies to reactor projects in the tycho-surefire-plugin: They only work if the test project already has some other dependency to the referenced reactor project. In your use case, where you add a dependency to a feature, this is not the case.
You could make the tycho-surefire-plugin dependencies configuration work again by adding a POM dependency to the feature project:
<dependencies>
<dependency>
<!-- Maven GAV of the feature project -->
<groupId>myproject.groupId</groupId>
<artifactId>myproject.app.feature</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-surefire-plugin</artifactId>
<version>${tycho-version}</version>
<configuration>
<dependencies>
<dependency>
<type>eclipse-feature</type>
<artifactId>myproject.app.feature</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</configuration>
</plugin>
</plugins>
</build>
However the recommended way to specify extra test dependencies is to do this in the target-platform-configuration instead of on the tycho-surefire-plugin:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<configuration>
<dependency-resolution>
<extraRequirements>
<requirement>
<type>eclipse-feature</type>
<id>myproject.app.feature</id>
<versionRange>1.0.0</versionRange>
</requirement>
</extraRequirements>
</dependency-resolution>
</configuration>
</plugin>
Note: The element names to specify dependencies are different in the target-platform-configuration compared to the tycho-surefire-plugin. So when migrating your configuration, you need to adapt the tag names:
<type> (unchanged)
<artifactId> → <id>
<version> → <versionRange>
Remark: Although the tag names are different, the semantics of the elements are the same: So even though the old name was <version>, the value was always interpreted as a version range. A version range that consists of a single version like 1.0.0 stands for for a version range without upper bound, i.e. version 1.0.0 or later.
I just had essentially the same problem. It seems that with tycho 0.21 dependencies have to be added using the target-platform-configuration plugin. See tycho bug 436617 comment #11 for an example.
Related
I have a fairly vanilla groovy project that builds using maven. It utilises the gmavenplus plugin, with the pom lifted straight from the gmaven plus web page
pom looks something like this:
<project>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>1.8.0</version>
<executions>
<execution>
<goals>
<goal>addSources</goal>
<goal>addTestSources</goal>
<goal>compile</goal>
<goal>compileTests</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<!-- any version of Groovy \>= 1.5.0 should work here -->
<version>2.5.8</version>
<type>pom</type>
</dependency>
</dependencies>
</project>
When I build, I get the following error on the compile stage.
[INFO] --- gmavenplus-plugin:1.8:compile (default) # myapp---
[INFO] Unable to get Groovy version from GroovySystem, trying InvokerHelper.
[WARNING] Unable to get Groovy version from InvokerHelper or GroovySystem, trying jar name.
[ERROR] Unable to determine Groovy version. Is Groovy declared as a dependency?
And the final maven error results in this:
[ERROR] Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.8:compile (default) on project myapp: Execution default of goal org.codehaus.gmavenplus:gmavenplus-plugin:1.8:compile failed. NullPointerException -> [Help 1]
I have tried all manner of tricks, hacks and cajoling to get it to compile. I actually got it working in Intellij by adding the groovy runtime as a direct module dependency (rather than a maven managed dependency), but this doesn't work from the command line.
I had previously had a similar setup working on gmaven plus 1.6 and groovy 2.4.7 on the same laptop, no idea why this is broken now.
So I eventually got it working properly by deleting the entire codehaus dir in the .m2 repo. Re-downloading everything seemed to sort it out and now it all works correctly without any hacks.
This github issue is somewhat related - https://github.com/groovy/GMavenPlus/issues/84 - and the final comment led me to zapping the repo.
Running maven (3.5.2) build of a Spring Boot 2.0.2.RELEASE applicaton (generated by web initialiser with web dependencies) fails executing the maven-surefire-plugin saying just:
Error: Could not find or load main class
org.apache.maven.surefire.booter.ForkedBooter
Caused by: java.lang.ClassNotFoundException: org.apache.maven.surefire.booter.ForkedBooter
Why is this happening? Is it a problem in boot + surefire integration = a bug?
For reference, the dependencies that seem relevant are:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.2.RELEASE</version>
<relativePath/>
</parent>
...
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
...
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
...
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
Workaround for the issue was to override Spring Boot's maven-surefire-plugin definition and set useSystemClassLoader to false. Read Surefire docs for more details
<build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<useSystemClassLoader>false</useSystemClassLoader>
</configuration>
</plugin>
</plugins>
</build>
The <useSystemClassLoader>false</useSystemClassLoader> solution provideded by jediz did allow my surefire tests to run, but broke class loading in some of my Spring Boot integration tests.
The following maven-surefire-plugin configuration worked for me:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
</configuration>
</plugin>
This is due to a known bug in the Maven Surefire plugin. It was fixed in version 3.0.0-M1, which was released in November 2018. So the simplest and most reliable fix is to upgrade which version of the plugin you use.
Updating the maven-surefire-plugin from 2.12.4 to 3.0.0-M1 worked for me. The project did not explicitly use the plugin, so I had to add a new plugin dependency.
<plugins>
...
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M1</version>
</plugin>
...
</plugins>
To me, the solution was to run mvn as
_JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true mvn clean compile package
Other ideas (giving the system property to the maven argument list, different changes in pom.xml, settings.xml) did not work.
Despite that it didn't contain the exact solution, also this answer was very helpful for me to make it clear, that it is an unfortunate cooperation of two independent, alone harmless bugs in the Ubuntu JDK and the Maven Surefire Plugin.
Recent Debian (buster) with the same JDK and Maven versions doesn't seem affected by the problem, but Ubuntu (xenial) did.
The exact solution is coming from this answer.
Update from the future: with Debian Buster is alles okay and this workaround is not needed any more.
I was able to remove the maven-surefire-plugin from my POM after adding this to the top of my POM (inside the <project> node)
<prerequisites>
<maven>3.6.3</maven>
</prerequisites>
Why do I think this is the right answer?
It specifies the version of Maven that Maven recommends using: https://maven.apache.org/download.cgi
when you run mvn versions:display-plugin-updates it shows that it's taking the maven-surefire-plugin 3.0.0-M3 from super-pom, which so far seems to have this issue fixed.
You don't have to manage individual plugin versions independently going forward. Just your minimum maven version which controls the super-pom version.
Adding this to the maven-surefire-plugin I resolved the problem:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkCount>0</forkCount>
</configuration>
</plugin>
I have a library with version 1.0.0-19 (19 is the Jenkins build number), on next jenkins build the version 1.0.0-20 will be assigend to the library and the artifact will be deployed to a maven repository. Another artifact which is referencing the library in the pom dependency section does not get the last version if I execute versions:use-latest-versions, the dependency version is still 1.0.0-19 instead of 1.0.0-20. Maybe it has to do with the allow* system parameters, there is no property for the build number part.
Any ideas how it could be achieved to get always the last build (1.0.0-19 -> 1.0.0-20)?
Within your pom make sure you are using -
<dependencies>
<dependency>
<groupId>some.artifactory.group</groupId>
<artifactId>artifact-name</artifactId>
<version>1.0.0-19</version>
</dependency>
</dependencies>
<!-- please use the appropriate artifact and groupId -->
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.3</version>
</plugin>
</plugins>
</build>
and you are executing the command -
mvn versions:use-latest-releases
Source - http://www.mojohaus.org/versions-maven-plugin/use-latest-releases-mojo.html
Note - Just in case this also involves SNAPSHOTS, do take care of allowSnapshots and use the command as -
mvn versions:use-latest-releases -DallowSnapshots=true
I have declared a OSGi bundle as a dependency in my maven project. ( It just happens to be the felix container. )
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.framework</artifactId>
<version>4.0.2</version>
<type>bundle</type>
<scope>compile</scope>
</dependency>
When I try to build, it says it can't find it.
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) org.apache.felix:org.apache.felix.framework:bundle:4.0.2
Try downloading the file manually from the project website.
But, a quick look in central verifies that this artifact is indeed there. I noticed that if I change it to a "jar" type, it will indeed download the jar ( bundle ) for me. Which got me to thinking, why did I call it a bundle in the first place? Well, I did that because when I was using m2e to lookup the artifact, it called it a "bundle"; in fact, m2e generated those coordinates that I cite above.
Is bundle not a valid maven artifact type? If not, why does m2e call it that?
This is not a glitch in m2e as mentioned in the accepted answer. The problem is that maven doesn't know what the type "bundle" is. So you need to add a plugin that defines it, namely the maven-bundle-plugin. Notice that you also need to set the extensions property to true. So the POM should have something like
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.4.0</version>
<extensions>true</extensions>
</plugin>
The problem with the accepted answer is that it works if the dependency of type bundle is a direct dependency; since it is your pom that declares it, you can just remove the type. However, if your dependency itself has a dependency of type bundle then you are screwed because then one of your transitive dependencies is of type bundle and you cannot just remove the type in it since you are not the owner of that artifact and don't have access to the pom, which again your current execution doesn't understand. it will try to look for repo/your-dependency.bundle
I ran into this problem when using the dependency plugin to copy-dependencies. In that case, the plugin dependency has to go in the plugin itself. You just need the dependency plugin to know about the bundle plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<dependencies>
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.4.0</version>
<type>maven-plugin</type>
</dependency>
</dependencies>
<extensions>true</extensions>
</plugin>
I am writing a project for acceptance testing and for various reasons this is dependent on another project which is packaged as a WAR. I have managed to unpack the WAR using the maven-dependency-plugin, but I cannot get my project to include the unpacked WEB-INF/lib/*.jar and WEB-INF/classes/* to be included on the classpath so the build fails. Is there a way to include these files into the classpath, or is there a better way of depending on a WAR?
Many thanks.
There's another option since maven-war-plugin 2.1-alpha-2. In your WAR project:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<attachClasses>true</attachClasses>
</configuration>
</plugin>
This creates a classes artifact which you can use in the acceptance tests project with:
<dependency>
<groupId>your-group-id</groupId>
<artifactId>your-artifact-id</artifactId>
<version>your-version</version>
<classifier>classes</classifier>
</dependency>
Indeed, by design, Maven doesn't resolve transitive dependencies of a war declared as dependency of a project. There is actually an issue about that, MNG-1991, but it won't be solved in Maven 2.x and I'm not sure that I don't know if overlays allow to workaround this issue. My understanding of the suggested solution is to duplicate the dependencies, for example in a project of type pom.
(EDIT: After some more digging, I found something interesting in this thread that I'm quoting below:
I have been helping out with the development of the AppFuse project over
the last month where we make heavy use of the war overlay feature in the
Maven war plugin. It is a really nifty feature!
To get max power with war overlays I have developed the Warpath plugin
that allows projects to use war artifacts as fully fledged dependencies.
In brief:
1) The contents of the /WEB-INF/classes directory in the war dependency
artifacts can be included in the project's classpath for normal compile,
etc tasks.
2) Transitive dependencies from the war dependency artifacts become
available for use by other plugins, e.g. compile and ear - so no more
having to include all the dependencies when creating skinny wars!
The plugin has now been actively used in the AppFuse project for the
last few months, and I feel it is at a point where it is both usable and
stable.
Would the war plugin team be interested in including the warpath
functionality inside the war plugin? It would seem to be the most
natural place to host it.
So, I don't have any experience with it, but the maven warpath plugin actually looks nice and simple and is available in the central repo. To use it,include the following plugin configuration element in your pom.xml file:
[...]
<build>
<plugins>
<plugin>
<groupId>org.appfuse</groupId>
<artifactId>maven-warpath-plugin</artifactId>
<version>1.0-SNAPSHOT</version>
<extensions>true</extensions>
<executions>
<execution>
<goals>
<goal>add-classes</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
And add the war dependencies you want included in the classpath as warpath type dependencies:
[...]
<dependencies>
<dependency>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-web</artifactId>
<version>2.0</version>
<type>war</type>
</dependency>
<dependency>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-web</artifactId>
<version>2.0</version>
<type>warpath</type>
</dependency>
</dependencies>
[...]
Both the war and warpath dependency types are needed: the war type is used by the Maven war plugin to do the war overlay, the warpath type is used by the Warpath plugin to determine the correct list of artifacts for inclusion in the project classpath.
I'd give it a try.)
Use overlays. First, your test project need to have also packaging war.
Declare dependency of war project you want to test:
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>your-project-arftifactId</artifactId>
<version>${project.version}</version>
<type>war</type>
<scope>test</scope>
</dependency>
then configure maven-war-plugin overlay:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webResources>
<resource>
<directory>${basedir}/src/main/webresources</directory>
<filtering>true</filtering>
</resource>
</webResources>
<overlays>
<overlay/>
<overlay>
<groupId>your.group</groupId>
<artifactId>your-project-artifactId</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
In the above example in test project I overwrite webresources configuration files (like conxtext etc.).
EDIT: This solution wasn't tested with Maven 3.
Good point, Justin. That got me actually solving my problem, namely: including a war into an assembly AND including all its transitive dependencies.
I could not duplicate the war-dependency as 'jar' as you suggested since the assembly plugin would not find a jar referenced by that groupId/artefactId, but
duplicating the war-dependency as type pom
works!
The war and its transitive dependencies are not included in the assembly.
To exclude the (now also appearing) pom file I had to add an exclude element like this:
<excludes>
<exclude>*:pom</exclude>
</excludes>
into my assembly.xml file.
I think this could also be a workaround for the original question of this thread.
If you list the dependency on the war project as a jar dependency it seems to pickup the required jars/resources. I'm using Maven 2.2 + m2eclipse.