Thanks Curtis and everyone.
I have a follow up question around the same thing build.
The command line I am using: maven clean install
Our 3.1.1 maven build is having issues finding the plugins in our .m2 directory unless I specify on the command line -Pmavencentral which is defined in our .m2/settings.xml as such:
<profile>
<id>mavencentral</id>
<repositories>
<repository>
<id>mcentral</id>
<url>http://sd-repo-2.eng.qpass.net:8081/nexus/content/repositories/central</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>mcentral</id>
<url>http://sd-repo-2.eng.qpass.net:8081/nexus/content/repositories/central</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
Which is our proxy to the public internet mavencentral server.
I have tried using the -o and -U switches at the command line when executing without the -Pmavencentral and I receive the following:
[ERROR] Plugin org.apache.maven.plugins:maven-shade-plugin:2.1 or one of its dependencies could not be resolved: Cannot
access qpass-nexus-hosted-releases (http://pd-repo2.eng.qpass.net:8081/nexus/content/repositories/releases) in offline
mode and the artifact org.apache.maven.plugins:maven-shade-plugin:jar:2.1 has not been downloaded from it before. -> [Help 1]
I want it to look only in the .m2 repository. Is there another -D setting I need to speciy? Is there some place I should be looking to see for conflicting settings?
-----Original Message-----
From: ctrueden.wisc [ at ] gmail.com [mailto:ctrueden.wisc [ at ] gmail.com] On Behalf Of Curtis Rueden
Sent: Friday, December 06, 2013 2:34 PM
To: Maven Users List
Subject: Re: plugin version ranges errors with Maven 3.1.1
Hi John,
You might be able to use profiles to define a different version of maven-shade-plugin depending on the version of Maven being used. However, some caveats:
1) There is no explicit profile activation for Maven version. The hack people use is to activate based on the existence of a property known only to e.g. Maven 3.x. I am not sure what a good property would be for Maven
3.1 specifically (i.e., not known to 3.0.x), but one probably exists.
2) When it comes to profiles, as Stephen Connolly likes to say: "that way madness lies." This hack will get your build done for you, but it is a hack, and you should never forget that it is a hack. Or to put another way:
it's technical debt. When the debt must be paid is unclear, but e.g. if the maven-shade-plugin produces a different binary result depending on which version you use, then you may run into apparently bizarre problems with users who built using Maven 3.1.1 rather than an older version, or vice versa, and it may take you some time to diagnose *why* it's happening
(surprise: it's because a different version of maven-shade-plugin got selected!), and so on.
Such problems are why the other posters in this thread are encouraging you to just choose a version of maven-shade-plugin that works for you. You
*can* put into your POM that it requires a certain minimum Maven version [1], and Maven will (IIRC) just fail fast if the version is too old. That is a lot less mysterious than some subtle inconsistency in shaded artifact build results. And you'll get truly repeatable builds which are one of the fabulous benefits of a well-structured build system.
Regards,
Curtis
[1] http://maven.apache.org/pom.html#Prerequisites
I have a follow up question around the same thing build.
The command line I am using: maven clean install
Our 3.1.1 maven build is having issues finding the plugins in our .m2 directory unless I specify on the command line -Pmavencentral which is defined in our .m2/settings.xml as such:
<profile>
<id>mavencentral</id>
<repositories>
<repository>
<id>mcentral</id>
<url>http://sd-repo-2.eng.qpass.net:8081/nexus/content/repositories/central</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>mcentral</id>
<url>http://sd-repo-2.eng.qpass.net:8081/nexus/content/repositories/central</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
Which is our proxy to the public internet mavencentral server.
I have tried using the -o and -U switches at the command line when executing without the -Pmavencentral and I receive the following:
[ERROR] Plugin org.apache.maven.plugins:maven-shade-plugin:2.1 or one of its dependencies could not be resolved: Cannot
access qpass-nexus-hosted-releases (http://pd-repo2.eng.qpass.net:8081/nexus/content/repositories/releases) in offline
mode and the artifact org.apache.maven.plugins:maven-shade-plugin:jar:2.1 has not been downloaded from it before. -> [Help 1]
I want it to look only in the .m2 repository. Is there another -D setting I need to speciy? Is there some place I should be looking to see for conflicting settings?
-----Original Message-----
From: ctrueden.wisc [ at ] gmail.com [mailto:ctrueden.wisc [ at ] gmail.com] On Behalf Of Curtis Rueden
Sent: Friday, December 06, 2013 2:34 PM
To: Maven Users List
Subject: Re: plugin version ranges errors with Maven 3.1.1
Hi John,
You might be able to use profiles to define a different version of maven-shade-plugin depending on the version of Maven being used. However, some caveats:
1) There is no explicit profile activation for Maven version. The hack people use is to activate based on the existence of a property known only to e.g. Maven 3.x. I am not sure what a good property would be for Maven
3.1 specifically (i.e., not known to 3.0.x), but one probably exists.
2) When it comes to profiles, as Stephen Connolly likes to say: "that way madness lies." This hack will get your build done for you, but it is a hack, and you should never forget that it is a hack. Or to put another way:
it's technical debt. When the debt must be paid is unclear, but e.g. if the maven-shade-plugin produces a different binary result depending on which version you use, then you may run into apparently bizarre problems with users who built using Maven 3.1.1 rather than an older version, or vice versa, and it may take you some time to diagnose *why* it's happening
(surprise: it's because a different version of maven-shade-plugin got selected!), and so on.
Such problems are why the other posters in this thread are encouraging you to just choose a version of maven-shade-plugin that works for you. You
*can* put into your POM that it requires a certain minimum Maven version [1], and Maven will (IIRC) just fail fast if the version is too old. That is a lot less mysterious than some subtle inconsistency in shaded artifact build results. And you'll get truly repeatable builds which are one of the fabulous benefits of a well-structured build system.
Regards,
Curtis
[1] http://maven.apache.org/pom.html#Prerequisites