I am trying to move from JDK 8 --> JDK 11 and sure enough maven surefire-plugin is failing. So I know that I need to change it's version to 2.21.0 or above that and I already did so. The version is only referenced in one pom so everything should be fine and even intellIJ says that I am using version 2.22.2.
The thing is I am when I run a mvn clean install -U or mvn test, or a mvn clean then mvn compile-test and lastly a test I am still getting error referencing:
Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on project modular-index-composer: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test failed.: NullPointerException
How is it even possible? I am 100% sure that the project must have a version of 2.22.2. Is there any other way where it could be set?
Kinda obvious/dumb solution:
So the project is made up of multiple modules, and there is a "parent" module that has most of the dependencies with their versions. I changed the sunfire version in this modules pom, and nothing seemed to be changing. (Eventhough intellij showed the correct newer version for the plugin)
So I decided to just exclude the parent pom and add the sunfire plugin with its version directly into my module. And behold it worked.
The issue is probably something with the parent pom, my guess would be that my module is not pulling from the correct parent pom version or it mixed it up somehow.
Related
I want to execute a maven plugin during mvn clean install whenever a file is changed since the last build. If the file is not changed since the last build then plugin execution should be skipped during mvn clean install.
Is it possible to achieve this in maven 3.5.0?
Maven doesn't keep record of all modules it ever built. However, this would be necessary if Maven would have to know if some (source) files changed.
Some plugins, like the maven-compiler-plugin, compare timestamps of source-files with timestamps of corresponding, generated class-files, which allows to skip compilation if classfile is newer. However, if you execute mvn clean (as mentioned in the question), class files are removed and compilation thus has to be executed anyway.
So to conculde: your request cannot be fulfilled by maven without major changes in maven itself.
I want to see the dependency tree of a project without actually downloading those dependencies.
I have a project whose build fails because there is some dependency which is not present in central repo, however it is not a direct dependency and I am not aware which one of my dependencies refers to it.
Now when I run mvn dependency:tree command, it builds the project and hence fails.
One way to do it is keep a dummy jar in local repo with the same name. It will not try to download the dependency and generate the entire tree. However is there any other way to do this ?
If you are using eclipse there is a "Maven POM Editor", which shows not only the maven XML, but also a dependency hierarchy view.
A working build is not necessary for it, just a correct POM XML file.
It should get installed, when you install the eclipse m2e plugin.
The update site is http://download.eclipse.org/technology/m2e/releases.
Maybe Maven dependency:analyze-only
mvn dependency:analyze-only
Analyzes the dependencies of this project and determines which are: used and declared; used and undeclared; unused and declared. This goal is intended to be used in the build lifecycle, thus it assumes that the test-compile phase has been executed - use the dependency:analyze goal instead when running standalone.
or dependency:resolve:
mvn dependency:resolve
mvn dependency:tree -DoutputFile=tree.txt
I have a project which I am attempting to install with maven. The pom.xml has a few properties in it which are modified when the maven install command is run depending on whatever version of a library we are attempting to build with:
<properties>
<some-version>0</some-version>
</properties>
The zero here is a placeholder, as we'll always specify a legitimate version during our build process. The version is then referenced later in the pom.xml to specify a few dependencies:
<dependencies>
<dependency>
<groupId>com.mycompany.myproduct</groupId>
<artifactId>someOtherProject</artifactId>
<version>${some-version}</version>
</dependency>
</dependencies
Building is done via make with the following commandline:
mvn -Dsome-version=1.6.2
Maven is able to correctly resolve the version and build as expected. However, the version being installed in my local maven repository (/home/user/.m2) doesn't have the correct version. The pom.xml that is installed does not have the updated version I set in the command line:
user#ubuntu:~/$ cat /home/user/.m2/repository/com/mycompany/myproduct/myproject/1.0.0/myproject-1.0.0.pom | grep some-version -C 1
<properties>
<some-version>0</some-version>
</properties>
--
<artifactId>someOtherProject</artifactId>
<version>${some-version}</version>
</dependency>
user#ubuntu:~/$
This is preventing any other project which depends on myproject from being able to build, as maven will complain that it can't find version 0 of someOtherProject:
[ERROR] Failed to execute goal on project myproject:
Could not resolve dependencies for project mycompany.myproduct:myproject:jar:1.0.0:
The following artifacts could not be resolved: com.mycompany.myproduct:someOtherProject:jar:0,
Could not find artifact com.mycompany.myproduct:someOtherProject:jar:0 in central (https://mycompany.com/artifactory/repo/) -> [Help 1]
What do I need to do for maven to install with the updated version in the pom? Obviously a terrible hackish solution would be to use sed and modify the pom file directly, but it seems that Maven should be able to actually leverage the command line settings when installing the pom. Otherwise the ability to set arguments on the command line seems remarkably limited in effectiveness.
Better you may set your property in pom.xml in <properties> tag like this -
<properties>
<property>
<name>some-version</name>
<value>1.6.2</value>
</property>
</properties>
If you use this then you don't have to provide the property each time you issue a mvn command from terminal.
mvn -Dsome-version=1.6.2 works as a substitution value for the scope of building than replacing the original POM with the new values. Hence is the behavior you see. I am not aware of any maven support to do so.
Under #JoopEggen's advice, I looked deeper into the maven versions plugin. It offered an update-property target which will actually update the pom.xml value on disk, rather than just passing in an overwrite during the build phase. I was able to solve my issue by calling
mvn versions:update-property -Dproperty=some-version -DnewVersion=1.6.2 -DsearchReactor=false -DallowSnapshots=true
in the makefile before calling mvn install. Disabling the reactor was necessary to prevent the plugin from rejecting values it couldn't find in the remote repo (see here), and allowSnapshots allows me to use version numbers such as 1.6.2-SNAPSHOT, useful when testing.
I'm working with a web app, called A, using maven, in eclipse, going between using m2e eclipse plugin and command line maven.
A depends on a custom library B, which is installed in the local repo. A details this dependency in its pom.xml
When I test the app in eclipse using eclipse's Tomcat, everything is fine -- the up-to-date version of B is used, and I see so in Maven dependencies folder.
But for some reason, when I go to command line and run mvn package, the resulting WAR uses out-dated version of B. I can tell because when I get it deployed to app server, its logging and functionality is broken in a specific way that was fixed in a newer version of B.
Is there any way for me to debug what's going on here? What is eclipse doing that mvn package is not including?
Project definition:
<groupId>org.com.web</groupId>
<artifactId>DocImgTransfer_Servlet</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
Dependency on lib that is somehow getting old version:
<dependency>
<groupId>DocImgTransfer</groupId>
<artifactId>DocImgTransfer</artifactId>
<version>1.0.0</version>
</dependency>
So really 3 questions:
If it is just some issue with maven grabbing the wrong version from local repo, is there a way for me to tell Maven to double-check the dependency version it's pulling in?
Will mvn clean or mvn package -U possibly help in this case at all?
Is the only advice to just double-check groupId, artifactId, version in pom.xml?
If it is just some issue with maven grabbing the wrong version from local repo, is there a way for me to tell Maven to double-check the dependency version it's pulling in?
a) Is your CustomatJar-1.0.0.jar version that eclipse is referring to same as maven is picking up or is maven picking up an older version?
i.e. Do you own the code for CustomatJar and are you just updating it v/s the one getting packed in war is truly an older version e.g. CustomatJar-0.0.5
i) You could tell by just unzipping the war and seeing which version is packed inside the jar.
ii) mvn dependency:dependency would tell you which dependencies maven command line thinks should be packed. more info
Is the only advice to just double-check groupId, artifactId, version in pom.xml?
Could you server have got an older version of CustomatJar in say it's lib?
You did double check your POM.xml already ... correct?
My Maven project has a dependency on a non-Maven library, which is coded as a system dependency:
<dependency>
<groupId>com.example</groupId>
<artifactId>foo</artifactId>
<version>${foo.version}</version>
<scope>system</scope>
<systemPath>${foo.jar}</systemPath>
</dependency>
where the location of the library can be controlled via local properties:
<properties>
<foo.version>2.1.1</foo.version>
<foo.basedir>/usr/local</foo.basedir>
<foo.libdir>${foo.basedir}/lib</foo.libdir>
<foo.jar>${foo.basedir}/java/foo-${foo.version}.jar</foo.jar>
</properties>
Recently, the library switched from version 2.1.1 to version 2.2.0, so I changed the foo.version property, but Maven seems to be stuck on the old version:
...
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) com.example:foo:jar:2.1.1
...
I have run mvn dependency:purge-local-repository (many times, actually). The string 2.1.1 does not appear anywhere in my POM, profiles.xml, or settings.xml. Still, every time I try to build my project, Maven fails with the above error.
What's going on here? Where is Maven storing the dependency version information and how can I update it?
I think the ${foo.version} might be getting resolved as a filter property. Can you check the properties file under src/main/filters.
Not sure if this is indeed the problem but just give it a try and update back.
The other reason that I could think of is - there might be a transitive dependency on com.example:foo:jar:2.1.1. That is some other dependency which needs 2.1.1 version of this artifact. You can find which artifact is bringing this transitively by doing mvn dependency:tree
You know what. Seeing the workaround that #Chris Conway found, I think that this might have been "solved" by simply running mvn clean.
And even if it would not have helped here, it is always worth trying mvn clean when something strange happens.
Dependency version conflict is a very common problem and most of the time when we start building our application, we never focus or generally we forgot on that aspect until and unless our application starts behaving in an unexpected way or getting started some exception.
For readers and visitors of SO who are interested in knowing the reason why dependency conflicts arises and how we can avoid them in our application , I found a source here explained in a precise way ,so i thought of adding my 2 bits to it .
http://techidiocy.com/maven-dependency-version-conflict-problem-and-resolution/
Cheers