I'm working on setup of arquillian testing. I want to deploy a WAR to JBoss using arquillian. This war is defined as a dependency in my pom.xml:
<dependency>
<groupId>my.project</groupId>
<artifactId>mywar</artifactId>
<version>1.0</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
But when I try to resove this dependency using shrinkwrap, it throws a NoResolvedResultException:
PomEquippedResolveStage resolver = Maven.configureResolver().workOffline().loadPomFromFile("pom.xml");
File war = resolver.resolve("my.project:mywar:war").withoutTransitivity().asSingleFile();
It seems that somehow the resolver isn't able to deal with war files. I experminted with org.jboss.shrinkwrap.resolver.api.ResolveWithRangeSupportStage.resolveVersionRange(String) as well and it seems to interpret the ":war" in the coordinates as the version - which obviously won't work.
If I supply the version, it works:
Maven.resolver().resolve("my.project:mywar:war:1.0").withoutTransitivity().asSingleFile();
But I need to make it work without the version because this will change by the time and I don't want to adapt the version on each release.
Any ideas?
Since your artifact is not JAR, I think you have to add a question mark. Your resolver should look like: .resolve("my.project:mywar:war:?")
Related
I am trying to use the FileUtils.writeStringToFile() method of the Apache Commons IO. Every bit of documentation says that I can do this:
FileUtils.writeStringToFile(File, String with data, boolean append);
I want this method, because I want the data to be written to the end of the file each time.
However, in Eclipse, it keeps telling me that this method does not exist. The only two I have are:
FileUtils.writeStringToFile(File, String with data);
FileUtils.writeStringToFile(File, String with data, String encoding);
I corrected my POM file to now have this dependency:
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.4</version>
</dependency>
Can someone please tell me what I am doing wrong?
Version 1.3.2 doesn't have this method, use a newer version of commons-io
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.4</version>
</dependency>
Check the FileUtils 2.4 javadoc
Turns out I was adding the Tomcat library files as well as the JRE library files to my project. Because when I deleted commons-io from my POM, I still had FileUtils available.
I had to get rid of the Tomcat library files from my build path, and once I put commons-io back in, it worked.
I have a project where I need the JNLP API. I did not find an artifact for that on Maven Central, so I added an external Repository which offers that to my pom. That repository went offline this weekend. This is the second time something like this happened to me.
I know this is pretty much what Maven is not about, but really I just want that tiny jnlp-api-1.5.0.jar file to be
In my SCM (I don't want to roll my own Maven repository for just one dependency).
In the compile scope when the project builds.
Which knobs do I have to turn to accomplish this?
As of JDK 7.0, the JNLP API is being provided by the javaws.jar file in your JRE's lib directory, i.e., ${java.home}/lib/javaws.jar. It is possible to use the maven dependency scope system.
<project>
...
<dependencies>
<dependency>
<groupId>javax.jnlp</groupId>
<artifactId>jnlp-api</artifactId>
<version>7.0</version>
<scope>system</scope>
<systemPath>${java.home}/lib/javaws.jar</systemPath>
</dependency>
</dependencies>
...
</project>
You can put the JAR in your local repository using the install-file goal of the maven-install-plugin and reference it as you normally would in your POM. The command would be:
mvn install:install-file -Dfile=/path/to/jnlp-api-1.5.0.jar -DgroupId=<group-id> -DartifactId=<artifact-id> -Dversion=1.5.0 -Dpackaging=<packaging>
Place this command in a script and check it into your SCM. That way, you (and anyone else working on this project) can install it easily to the local repo.
Maven2 checks for updates of stax-ex at every build. And it's just checking this single dependency, all other dependencies are updated only once per day.
Maven2 output:
artifact org.jvnet.staxex:stax-ex: checking for updates from java.net
stax-ex (groupid: org.jvnet.staxex, version: 1.2) is included as part of jaxws-rt (groupid: com.sun.xml.ws, version: 2.1.3). We have an artifactory repository as intermediary.
What could I do? ( Building offline would be an unpopular work-around.)
I had the same problem, and wanted to get to the bottom of it!
The problem is in the pom.xml file of streambuffer (a dependency of jaxws-rt), which doesn't specify a version for stax-ex. Instead, it uses RELEASE, meaning the latest released version:
<dependency>
<groupId>org.jvnet.staxex</groupId>
<artifactId>stax-ex</artifactId>
<version>RELEASE</version>
</dependency>
This forces Maven to check constantly for the latest release of stax-ex (even if jaxws-rt itself requests version 1.2), by downloading its corresponding maven-metadata.xml.
An easy workaround is to force the version of stax-ex in a dependencyManagement section of your pom.xm:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jvnet.staxex</groupId>
<artifactId>stax-ex</artifactId>
<version>1.2</version>
</dependency>
</dependencies>
</dependencyManagement>
And then Maven will stop bothering you about this warning...
It looks like you have remote repository declarations in your POMs that bypass your enterprise repository. If you are using Artifactory you can either have remote repository references in POMs automatically stripped off on a virtual repository level, or configure mirror-any in your settings to enforce artifact resolution go strictly through your Artifactory.
I have two maven modules, one that ends up as a jar, and one war that depends on that jar.
I want the jar module to package it's source code together with the compiled classes in the jar, so that the second module is able to access it. I have tried using the maven-source-plugin, but I am confused as to how to add a dependency on the output of that. It seems that the dependency by default goes to the compiled jar, and not the source-code jar (ending with "-source.jar") that maven-source-plugin creates.
How do I add the "-source.jar" as a dependency, while still preserving the dependency on the compiled sources?
I've not tried this, but I think you need to create two profiles in your project. One which builds the main jar. The other which builds the sources jar. Unfortunately, I'm not exactly sure how you would build that profile. I couldn't find a good example of it so far.
(Accoding to the comments, you don't actually need a profile. You can just use the sources-plugin which will deploy the sources and make them available via the sources classifier)
In theory, you'd use the 2nd profile to attach the sources to the project. This creates a 2nd entry in your repository for the sources using that classifier. Once you install/deploy the sources to your repository, you should be able to include the sources as a dependency by using the classifier tag on the dependency to specify the sources directly.
So you'd have something like this in your webapp POM:
<dependencies>
<dependency>
<groupId>myGroup</groupId>
<artifactId>myJar</artifactId>
<version>4.0</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>myGroup</groupId>
<artifactId>myJar</artifactId>
<version>4.0</version>
<type>jar</type>
<classifier>sources</classifier>
</dependency>
</dependencies>
Did you try adding the src directory as a resource directory in the build section? That should copy the source into the jar on build.
Does anyone know of a way to set a specific classpath order in Maven2, rather than the random ordering I appear to experience at the moment?
There are a number of legitimate reasons for wanting to do this:
A vendor has supplied a patch jar, which contains overriding classes for a previously released jar and therefore the patch jar must appear first in the classpath ordering.
Two jar's found on the classpath discovered by traversing pom dependencies contain the same class in the same package with different signitures. For example:
jboss
jbossall-client
4.2.0.GA
org.hibernate
hibernate
3.1
both contain:
org.hibernate.util.ReflectHelper.class, but the jbossall-client version is missing the getFastClass method.
From googling I see that this is perhaps a point of contention between maven enthusiasts and people facing this particular issue, but surely there are legitimate reasons for classpath ordering.
Any advice from anyone that has solved this particular quandary would be much appreciated!
Thanks
As of version 2.0.9 maven uses pom order for classpath, so you can actually manipulate it now. We mostly supress transitive dependencies to external libraries that we also include directly.
From the release notes of maven 2.0.9:
MNG-1412 / MNG-3111 introduced deterministic ordering of dependencies on the classpath. In the past, natural set ordering was used and this lead to odd results. The ordering is now preserved from your pom, with dependencies added by inheritence added last. In builds that had conflicting or duplicate dependencies, this may introduce a change to the output. In short, if you have weird issues with 2.0.9, take a look at the dependencies to see if you have conflicts somewhere.
Maven 2.0.9 adds correct ordering so you absolutely must have that version or higher for the below to work.
Secondly you need the an updated plugin. The Maven guys are working on a fix, its in their jira to fix but this is something I urgently needed. So in the meantime I have fixed this myself and you can pull the Modified plugin source code from github.
Edit: Refer to http://jira.codehaus.org/browse/MECLIPSE-388
There are two ways to install it, either pull my modified code and install it or download the prebuilt jar and just add it.
Building the plugin
Run maven install from the plugin directory you checked out and then add the following in your plugins section of your projects pom:
<build>
</plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<version>2.8-cpfix</version>
</plugin>
</plugins>
</build>
Download the jar
Alternatively if you don't want to download and compile yourself then you can just get hold of the jar file and install it yourself.
Once you have the file run
mvn install:install-file -Dfile=<path-to-file> -DgroupId=org.apache.maven.plugins \
-DartifactId=maven-eclipse-plugin -Dversion=2.8-cpfix -Dpackaging=jar
Regardless of how you installed it now when you run mvn eclipse:eclipse it will pick up the modified code and order the dependencies based on the order you defined in your pom file, no alphabetical ordering. It will also put the JRE container at the top of the dependencies.
Hopefully the real version of this code will come out soon, but in the meantime this fix has worked for me on my project and I hope it can help some others as well.
Rather a further qualification of the question than an answer:
under "Maven Dependencies" Eclipse does not seem to honour the POM-order.
(it does use the POM-order under "Java Build Path" & in the Classpath)
Is that the expected behaviour?
I'm using Eclipse 2021-09 (which has Maven 3.8.1 embedded) under Windows 10.
Here's the POM:
<project
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.group</groupId>
<artifactId>arty.fact</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>Maven Dependency Order</name>
<properties>
<maven.compiler.target>17</maven.compiler.target>
<maven.compiler.source>17</maven.compiler.source>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>wsdl4j</groupId>
<artifactId>wsdl4j</artifactId>
<version>1.6.3</version>
<exclusions><exclusion><groupId>*</groupId><artifactId>*</artifactId></exclusion></exclusions>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.1</version>
<exclusions><exclusion><groupId>*</groupId><artifactId>*</artifactId></exclusion></exclusions>
</dependency>
</dependencies>
</project>
The Maven Dependencies looks like this:
If you have problem starting with IntelliJ IDEA, you can change the dependencies order from project structrue.