I've got a dependency on tools.jar in my project, which is a javac plugin. It can be configured to be run in a Maven build. So there's a maven plugin to enable a javac plugin.
This can be done by following the Maven FAQ:
http://maven.apache.org/general.html#tools-jar-dependency
includes
<systemPath>${java.home}/../lib/tools.jar</systemPath>
The problem is that the mvn release pom expands all variables, so when I've released my maven plugin, it refers to a hardcoded jdk path from the machine where the release was performed, rather than a variable to resolve it at runtime on the client machine.
That obviously causes my Maven plugin to fail to include tools.jar on the classpath.
I can't find any way to convince the maven release plugin to leave this variable in the output. Any ideas?
Bug reference: https://code.google.com/p/error-prone/issues/detail?id=18
Related
I am getting this error: [ERROR] Plugin org.apache.maven.plugins:maven-surefire-plugin:2.12.4 or one of its dependencies could not be resolved: Could not find artifact org.apache.maven.plugins:maven-surefire-plugin:jar:2.12.4 in nexus-xyz-plugin
I tried to run maven with dependecy:tree, but I can't see surefire, and I dont know why it is looking for this specific version 2.12.4 which is not specified in my pom!
Even the surefire plugin is not defined in my pom, but I have the assembly plugin not sure if assembely is dependent on surefire
Note that I only get the error when running mvn package, however when running mvn compile the build succeeds
Version 2.12.4 of the maven-surefire-plugin is always added to the pom by maven version 3.x unless you depend on a specific other version.
Maven has a so called super pom that you get for free, but that doesn't list surefire: https://maven.apache.org/ref/3.8.5/maven-model-builder/super-pom.html
However it is added to the pom, i've checked this with maven 3.3.9. You can verify this by running mvn help:effective-pom.
Reference with the same problem: No surefire plugin in my pom - How does it show surefire output?
These plugin versions are part of the default bindings for lifecycle executions, in this case of the test phase. So these plugins are always included if not specified.
See for reference:
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
https://maven.apache.org/ref/3.8.5/maven-core/default-bindings.html
Maven default life-cycle and plugins section
Normally this plugin should be available in maven central, check if you have a <pluginRepository> in your (effective) pom that references https://repo1.maven.org/maven2/
Some other things you can check:
Open the file .m2\repository\org\apache\maven\plugins\maven-surefire-plugin\2.12.4\maven-surefire-plugin-2.12.4.jar.lastUpdated and check the error message for each repository. Check why it can't reach maven central; is it missing from the list or giving an error? This might be a company firewall/policy issue perhaps? Or is it giving an error on HTTPS/TLS protocol level?
Check if you can add maven central to your repositories list if it's missing somehow (should be included by default). Check if it's HTTP or HTTPS, only secure is supported now.
Run your maven command with -X for debug mode to investigate further
An alternative is to add the latest version of surefire to your project that is available in your plugin-repository, and perhaps disable it if you're not executing unit tests.
See Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on project.
I read on Java 9 Modularity book:
Dependencies are always put on the module path, even when dependency isn't modularized yet.
[...]
The most important changes made to Apache Maven for support of the Java module system are as follows:
Uses the modulepath during compilation
Supports a mix of explicit modules and automatic modules as dependencies
I'm looking at maven documentation and I cannot find this information anywhere.
Does maven by default add <dependencies> to the modulepath (only?) and if yes, after which maven version?
Also if the above is true is there a way to instruct maven to not use modulepath at all?
No, Maven puts dependencies to module path only for those Maven modules that have module descriptors (module-info.java). Non-modular Maven modules still put their dependencies to classpath.
You can run Maven with -X option to see exact command-line options that are passed to javac.
I've discovered the wonderful test-jar facility in Maven: https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html
But it may so happen that one project needs to use the test-jar of another project. From https://stackoverflow.com/a/6469256/421049 and experimentation, it would seem that using mvn install does not install the test-jar to the local ~/.m2/repository. So how does one project on my machine use the test jars of another project not in the same aggregate POM?
Yet it would seem from Maven deploy not to upload test jar that deployment of a project to Maven Central does in fact deploy the test-jar? So I can deploy it to Nexus but not install it locally? And if I deploy it to Nexus, will my local project using a dependency of <type>test-jar</type> go find it on Maven Central?
It turns out that maven-jar-plugin does in fact install the test-jar (e.g. foo-1.2.3-tests.jar) in the local Maven repository ~/.m2/repository/.... Wonderful!
My problem is that I had inadvertently configured the maven-jar-plugin to be in a separate profile named release. (I had copied and pasted to the wrong location in my POM.) That's why the test-jar didn't show up in my local repository after a mvn install, and that's why it suddenly showed up later (after I used -P release once in testing), and I thought I had just missed it when I looked the first time.
I move the maven-jar-plugin to the <build> section and everything is working fine: the test-jar gets put into the local maven repository using mvn install.
In my case, I was setting maven.test.skip for a particular build profile. That property actually causes tests to not be compiled/installed, thus also preventing their deploy. The solution was to set the skipTests property instead.
I am new to maven.
The POM file in maven contains all the dependencies that we need in our project.
So we don't have to externally add any JAR's to the buildpath in eclipse.Right?
That's right. Maven will download dependencies and M2Eclipse (Eclipse plugin for integrating Eclipse with Maven) will setup a build path for you.
Two Solutions - 1 Using Eclipse IDE
Install the Maven (M2E Eclipse Plugin) if you use older version of eclipse, If you download the latest eclipse.
Point your settings.xml and create a maven project from your eclipse, it is better keep Group Id as com.yourcompany.app Artifact Id as yourProjectName and Version 0.0.1-SNAPSHOT depends on your Architecture Standards set by your company. Also Packaging can be as WAR file for WebApplication, EAR file for Enterprise Application. You can find the numerous list of examples from Maven Site.
2 From Command Line
Install Maven from Apache Maven site, Would recommend to go for the latest version -apache-maven-3.3.9-bin.zip.
Set the Maven Home in the Environment Variables as shown in the below figure.
Edit Your Path variable as %MAVEN_HOME%\bin, verify your installation by using this command from your command prompt. It should display the Maven Home and Java Version, which confirms your maven successful installation.
Paste your settings.xml (C:\apache-maven-3.3.9\conf) given by your build team or Architecture team for accessing your internal repository. And keep a backup of the original settings.xml (which is default download from Maven site)
Run these commands from your command prompt.
mvn eclipse:clean -e
mvn eclipse:eclipse -e (which will automatically set your project build path as shown in the below figure)
It will resolve your compilation issues and your project is ready as an deploy-able artifact
With maven-3, it uses aether to resolve dependency.
Unfortunately, "mvn dependency:tree" use legacy (maven-2) resolution engine.
How do I find out the true dependency resolution for maven-3. I'm running into an issue where "exec:exec" creates different classpath then "dependency:tree".
In maven 3 - compatibility notes, it says I need to use "-X" and look at the log but there is no pointer what to look for.
Also, "assembly:assembly" brings in different 'jar' than when I print out classpath from "exec:exec".
dependency:tree is the correct way to get the project dependencies. Since version 2.5 of the plugin it now resolves the tree using aether.
exec:exec runs the maven exec plugin. The classpath it generates is based on the plugin dependencies, if specified. It is relevant only for the purpose of the plugin execution and not to be taken in the context of project.
The similar explanation holds good in case of assembly:assembly. The jars that it brings in entirely depends on the plugin and assembly-descriptor configuration.
Since version 2.5 of the Maven Dependency Plugin, dependency:tree works with Maven 3 (see the bug report, and the release notes)