Unfortunately I don't believe that solves the problem. We actually do not have the Shade plugin in our repositories and so I manually place it into our .m2 repository into the right place. The reason this is happening because our organization is big and adding anything to our repository takes a papal bull and a month of testing. I am trying to build an argument for our architects to upgrade to Maven 3.1.1 which solves several bugs we're running into.
That is why I am doing all of this. Now, I want to force it to look in .m2 before going anywhere else. I thought if I used the -o flag to tell I to work offline it would do this, however it isn't. Is there a way to force it to look in the .m2 for what it needs rather than having to go to mavencentral? -----Original Message----- From: Ron Wheeler [mailto:[email protected]] Sent: Friday, December 06, 2013 3:15 PM To: [email protected] Subject: Re: Version resolution question (was: plugin version ranges errors with Maven 3.1.1) <mirrors> <mirror> <id>nexus</id> <mirrorOf>*</mirrorOf> <url>http://repo.....com:8081/nexus/content/groups/public</url> </mirror> </mirrors> This might help Ron On 06/12/2013 6:06 PM, John Dix wrote: > 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/release > s) 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: [email protected] [mailto:[email protected]] 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 > > > On Fri, Dec 6, 2013 at 4:20 PM, John Dix <[email protected]> wrote: > >> We are getting build failures when using 3.1.1 and the 2.0 shade plugin. >> It seems to be a documented issue: >> >> https://issues.apache.org/jira/browse/STANBOL-1212 >> >> So I wanted to be able to have the same parent pom for our builds >> that still require 3.0.5 which currently sets it to 2.0 and does not >> run into this error. >> >> -----Original Message----- >> From: Wayne Fay [mailto:[email protected]] >> Sent: Friday, December 06, 2013 12:51 PM >> To: Maven Users List >> Subject: Re: plugin version ranges errors with Maven 3.1.1 >> >>> Agreed however I need to support two builds in our environment one >>> that uses Maven 3.0.5 and one that does 3.1.1 without having to >>> change >> the file every time. >> >> Sorry for asking the obvious question, but what prevents you from >> specifying version [2.0] or whatever and using that with both 3.0.5 >> and 3.1.1? Is there some incompatibility I am unaware of presently? >> >> Wayne >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> This message and the information contained herein is proprietary and >> confidential and subject to the Amdocs policy statement, you may >> review at http://www.amdocs.com/email_disclaimer.asp >> > This message and the information contained herein is proprietary and > confidential and subject to the Amdocs policy statement, you may > review at http://www.amdocs.com/email_disclaimer.asp > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Ron Wheeler President Artifact Software Inc email: [email protected] skype: ronaldmwheeler phone: 866-970-2435, ext 102 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
