maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Version resolution question
Date Sat, 07 Dec 2013 02:03:59 GMT
I think that you have a pretty good grasp of the situation now and 
should be able to make your case.

Good luck


On 06/12/2013 8:02 PM, John Dix wrote:
> No it isn't a good thing. I never said it was. However I am trying to make a case for
upgrading and in order to do that I need to test against all of our code in a sandbox environment.
I am having issues building and was hoping to have those resolved. :)
> -----Original Message-----
> From: Ron Wheeler []
> Sent: Friday, December 06, 2013 5:00 PM
> To:
> Subject: Re: Version resolution question
> I took a quick visit to your web site and I can see why security and stability trumps
> I am not sure how working around the corporate security regime would be a good thing.
> Sometimes you just have to honour the trade-offs that management makes and let them pay
for them.
> If your projects take longer and get blocked, you just have to down tools and wait (preferably
in an executive office) until the decisions and testing get finished.
> Good luck.
> Ron
> On 06/12/2013 7:38 PM, John Dix wrote:
>> Yes and Yes.
>> It took us 6 months to upgrade from 3.0.3 to 3.0.5 which still hasn't happened or
released product yet.
>> -----Original Message-----
>> From: Ron Wheeler []
>> Sent: Friday, December 06, 2013 4:32 PM
>> To: John Dix; Maven Users List
>> Subject: Re: Version resolution question
>> Have you provided the Pope with a list of the bugs that have been fixed since the
2.1 shade plug-in?
>> Do they understand the great risk and horrible problems to which they are exposing
your organization by using a plug-in and an old Maven with known bugs?
>> Good luck.
>> It is hard enough to fight the bugs that one creates without a corporate structure
making progress more difficult.
>> Ron
>> On 06/12/2013 6:44 PM, John Dix wrote:
>>> Sorry, I meant we do not have Shade 2.1 plugin. 2.0 is in our repository.
>>> -----Original Message-----
>>> From: John Dix
>>> Sent: Friday, December 06, 2013 3:25 PM
>>> To: Maven Users List;
>>> Subject: RE: Version resolution question (was: plugin version ranges
>>> errors with Maven 3.1.1)
>>> 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 []
>>> Sent: Friday, December 06, 2013 3:15 PM
>>> To:
>>> Subject: Re: Version resolution question (was: plugin version ranges
>>> errors with Maven 3.1.1)
>>>      <mirrors>
>>>         <mirror>
>>>           <id>nexus</id>
>>>           <mirrorOf>*</mirrorOf>
>>> <url></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></url>
>>>>               <releases>
>>>>                 <enabled>true</enabled>
>>>>               </releases>
>>>>               <snapshots>
>>>>                 <enabled>false</enabled>
>>>>               </snapshots>
>>>>             </repository>
>>>>           </repositories>
>>>>           <pluginRepositories>
>>>>             <pluginRepository>
>>>>               <id>mcentral</id>
>>>>               <url></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
>>>> (
>>>> s
>>>> e
>>>> 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: [] 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]
>>>> On Fri, Dec 6, 2013 at 4:20 PM, John Dix <> wrote:
>>>>> We are getting build failures when using 3.1.1 and the 2.0 shade plugin.
>>>>> It seems to be a documented issue:
>>>>> 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 []
>>>>> 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
>>>>> -------------------------------------------------------------------
>>>>> -
>>>>> -

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message