I am using JBoss Shrinkwrap 3.1.4 to resolve dependencies for given Maven coordinates. To achieve this, the following code is doing a fine job in most cases:
var artifacts = Maven.configureResolver()
.withClassPathResolution(false)
.loadPomFromFile(f)
.importCompileAndRuntimeDependencies()
.resolve()
.withTransitivity()
.asResolvedArtifact();
However, in some cases Shrinkwrap is not able to build the POM model and identifies validation problems in the POM file. For example, for javax.mail:mail:1.4.3, I get the following error message:
org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException: Found 4 problems while building POM model from /root/.m2/repository/javax/mail/mail/1.4.3/mail-1.4.3.pom
1/ [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. # javax.mail:mail:1.4.3, /root/.m2/repository/javax/mail/mail/1.4.3/mail-1.4.3.pom
2/ [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-jar-plugin is missing. # javax.mail:mail:1.4.3, /root/.m2/repository/javax/mail/mail/1.4.3/mail-1.4.3.pom
3/ [WARNING] 'build.plugins.plugin.version' for org.apache.felix:maven-bundle-plugin is missing. # javax.mail:mail:1.4.3, /root/.m2/repository/javax/mail/mail/1.4.3/mail-1.4.3.pom
4/ [ERROR] 'build.plugins.plugin.version' for org.codehaus.mojo:findbugs-maven-plugin must be a valid version but is 'RELEASE'. # javax.mail:mail:1.4.3, /root/.m2/repository/javax/mail/mail/1.4.3/mail-1.4.3.pom
I am only interested in the dependencies... these problems in the build section (like error 4) are irrelevant for me. I am wondering, if it is somehow possible to reduce validation strictness when processing the POM files (or disable it altogether), but I could not find anything in the APIs.
Any pointer would be appreciated.
best
Sebastian
Related
When I use the maven-release-plugin and run it then I see several warning messages:
[INFO] [WARNING] Some problems were encountered while building the effective model for li.pitschmann:knx-core:jar:0.0.1
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-source-plugin is missing. # org.apache.maven:maven-model-builder:3.6.1:super-pom, jar:file:/Applications/IntelliJ%20IDEA%20CE.app/Contents/plugins/maven/lib/maven3/lib/maven-model-builder-3.6.1.jar!/org/apache/maven/model/pom-4.0.0.xml, line 113, column 19
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-javadoc-plugin is missing. # org.apache.maven:maven-model-builder:3.6.1:super-pom, jar:file:/Applications/IntelliJ%20IDEA%20CE.app/Contents/plugins/maven/lib/maven3/lib/maven-model-builder-3.6.1.jar!/org/apache/maven/model/pom-4.0.0.xml, line 125, column 19
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-deploy-plugin is missing. # org.apache.maven:maven-model-builder:3.6.1:super-pom, jar:file:/Applications/IntelliJ%20IDEA%20CE.app/Contents/plugins/maven/lib/maven3/lib/maven-model-builder-3.6.1.jar!/org/apache/maven/model/pom-4.0.0.xml, line 137, column 19
How can I set the version of 'maven-source-plugin', 'maven-javadoc-plugin' and 'maven-deploy-plugin' although I do not have those defined in my pom.xml file. It looks like those three plugins are invoked by 'maven-release-plugin'. To define the version of those three plugins (which are invoked by maven-release-plugin) do I have to add and define them in <pluginManagement> explicitly or is there a way possible through maven-release-plugin?
It is for me a surprise that none complained about this issue; so I am worried if I am on wrong path. At least I could not find same issue in stackoverflow, issues reported here seems be only similar but have other error sources. Clarifications are appreciated!
I'm using the Maven shade plugin, and I get output like the following from mvn package:
[WARNING] kryo-4.0.0.jar, kryo-2.21.jar define 91 overlapping classes:
followed by:
[WARNING] maven-shade-plugin has detected that some class files are
[WARNING] present in two or more JARs.
[WARNING] single version of the class is copied to the uber jar.
[WARNING] Usually this is not harmful and you can skip these warnings,
[WARNING] otherwise try to manually exclude artifacts based on
[WARNING] mvn dependency:tree -Ddetail=true and the above output.
On the other hand, there are many other jars that I would expect to get such warnings for, but I don't. In particular, if I do mvn dependency:tree -Dverbose, I get a lot of output like:
[INFO] | | +- (org.apache.commons:commons-lang3:jar:3.3.2:compile - omitted for conflict with 3.5)
My question is, why do some cases of duplicate classes result only in the "overlapping classes" warnings, while other cases result only in the "omitted for conflict" information messages?
The groupId of kryo changed from version 2.x to 3.x. This means that technically, kryo 4.0.0 and kryo 2.21 are different artifacts for Maven. No dependency mediation occurs, they are just put both on the classpath. This is why the shade plugin complains.
I am trying to build the project
https://github.com/itext/i5js-sandbox/
I've tried
mvn eclipse:eclipse
mvn update
mvn package
but I got this error
[WARNING] The POM for com.itextpdf:itextpdf:jar:5.5.11-SNAPSHOT is missing, no dependency information available
[WARNING] The POM for com.itextpdf.tool:xmlworker:jar:5.5.11-SNAPSHOT is missing, no dependency information available
[WARNING] The POM for com.itextpdf:itext-pdfa:jar:5.5.11-SNAPSHOT is missing, no dependency information available
[WARNING] The POM for com.itextpdf:itext-xtra:jar:5.5.11-SNAPSHOT is missing, no dependency information available
You are trying to build the examples without first building the jars on which the examples depend. You have two options:
Either use iText 5.5.10 instead of 5.5.11-SNAPSHOT. 5.5.10 has been officially released and the jars you need are published on the Maven Central repository.
Or use iText 5.5.11-SNAPSHOT and build everything yourself. Mind the word everything, starting with the core.
Suppose that you were building a house. You are trying to build the roof in the air, and you complain that the roof falls down. That's wrong. You shouldn't start with the roof. You should start with the foundations and the walls.
I am starting out with Maven, following a book. I'm using 3.2.1 on Ubuntu. I have run the following commands:
mvn archetype:generate -DgroupId=org.sonatype.mavenbook.ch03 -DartifactId=simple -DpackageName=org.sonatype.mavenbook
mvn install
I then get a beanstalk error. Essentially, I don't have Amazon credentials. I understand the concepts surrounding Maven. What if I don't want to use Amazon services? Is this really necessary?
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.sonatype.mavenbook.ch03:simple:war:1.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. # line 143, column 12
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building simple 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- beanstalk-maven-plugin:0.2.8:expose-security-credentials (expose-security-credentials) # simple ---
[WARNING] FAILURE
java.lang.IllegalArgumentException: Settings for serverId ('aws.amazon.com') not found. See http://beanstalker.ingenieux.com.br/beanstalk-maven-plugin/security.html for more information
You probably used the elasticbeanstalk archetypes. A short reason (as it seems you're just learning Maven) is to edit your pom and remove the <plugin/> sections for br.com.ingenieux groupId.
Hope it helps
For those who care about the little details on why did it fail
Since release 1.3.x (a few weeks ago), we dropped the usage of aws.accessKey and aws.secretKey. The warnings were there for more than two years in fact :)
Reason: Many projects on github were leaking AWS Keys
Instead, set those as environment variables (AWS_ACCESS_KEY_ID) and (AWS_SECRET_ACCESS_KEY) or use encryption - see this doc for an overview
When I build my project, I get these warnings:
[INFO] ------------------------------------------------------------------------
[INFO] Building XXX
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for org.eclipse.update:org.eclipse.update.configurator:jar:3.2.0 is missing, no dependency information available
[WARNING] The POM for org.eclipse.emf:org.eclipse.emf.ecore:jar:2.3.2 is missing, no dependency information available
[WARNING] The POM for com.ibm.icu:com.ibm.icu:jar:3.4.4 is missing, no dependency information available
In my build, I overwrite the versions of these dependencies and the build itself succeeds.
What is the fastest way to fix the warnings?
Edit: What is the fastest way to locate the POMs which contain these versions?
Note: I have 7000 POMs in my local repo.
try the analyze tools from the dependency-plugin
especially the mvn dependency:analyze-dep-mgt
A few things that might help:
mvn dependency:tree -Dverbose=true can spit out unused duplicates/versions. Wasn't enough in my case, however, for some reason it didn't show the offending jar's listed [?]. It also doesn't show the ommitted jar's descendants, which may or may not be useful.
ref: http://jira.codehaus.org/browse/MDEP-123
Intellij can list what it thinks are offending pom's and paths (open the pom.xml file, hover over the underlined "project":
Unfortunately none of these was enough for me, either.
Then I noticed that if you delete the offending directory from your ~/.m2/repository, it will be downloaded again and basically empty. So I think what this error message can sometimes mean is "your nexus lists a version that it doesn't actually have available for download." It appears that maven by default, if you request for instance commons-logging 1.1.1, will attempt to download the pom's for all known versions of common-logging, then, in my case, it spit out that warning but it was benign. Phew!
So in truth, none of your projects might point to the warned of bad pom (or bad version, etc.) Except nexus' metadata index.
You could use dependency:tree to see what pom references the one you're missing