Re: Pain with MNG-5181 (_maven.repositories)

[Olivier Lamy <ol...@apache.org>]

I have pushed a fix for that.
Now you can desactivate the enhanced local repository using:
* new cli option: -slrm,--simple-local-repository-manager
* or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true

will be available for testing here
https://builds.apache.org/job/maven-3.x/ with build #368


2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
> Hi Arnaud,
>
>> +1 to consider the current behavior as a bug.
>> We should be able to deactivate it easily (and perhaps to have it off by
>> default to activate it only on CI servers)
>
> :)
>
>> and we should take care to have
>> a real error message explaining the issue and not a classical dependency
>> not found while the artifact is in the local repo.
>
> This is exactly filed here:
> http://jira.codehaus.org/browse/MNG-5185
>
>>
>> Arnaud
> Cheers
>   Jörg
>
> --
> If know-how becomes know-where, then knowledge gets nowhere.
>   [Jörg Hohwiller]
>



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Pain with MNG-5181 (_maven.repositories)

[Jörg Schaible <Jo...@scalaris.com>]

Andreas Gudian wrote:

>  Am Freitag, 1. Februar 2013 schrieb Jason van Zyl :
> 
>>
>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier
>> <aheritier@gmail.com<javascript:;>> wrote:
>>
>> > Hi Olivier,
>> >
>> >  Thx a lot for the fix. It will help a lot the community.
>> >  But from my point of view it's perhaps not yet enough.
>> >  We should :
>> >  1/ change the default behavior to deactivate this control which is
>> > difficult to understand
>>
>> I disagree. We may want to change it slightly but it's only a problem for
>> people who flip between Maven a repository manager and without but it's
>> to ensure the identity of a component. I haven't seen a huge number of
>> complaints. I do not want to turn this off. Improve it, sure, but turning
>> it off by default I believe is not the right thing to do.
>>
>>
> How about turning it into a warning by default and only fail if you enable
> some meaningful option (or implicitly in some plugins such as the release
> plugin).
> 
> But I must admit that I don't really have a use case in mind where failing
> is crucial.

We have a private plugin from an internal repository which has a goal that 
is executed during the build and a goal to generate a report. Unfortunately 
the jar of the plugin can no longer be resolved when it should generate the 
report. As it turns out, the site plugin is too old (3.0-beta-3). However, 
any newer version has a bug (MSITE-604) and site:deploy fails i.e. we cannot 
release with it. Catch-22.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Pain with MNG-5181 (_maven.repositories)

[Andreas Gudian <an...@gmail.com>]

 Am Freitag, 1. Februar 2013 schrieb Jason van Zyl :

>
> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <aheritier@gmail.com<javascript:;>>
> wrote:
>
> > Hi Olivier,
> >
> >  Thx a lot for the fix. It will help a lot the community.
> >  But from my point of view it's perhaps not yet enough.
> >  We should :
> >  1/ change the default behavior to deactivate this control which is
> > difficult to understand
>
> I disagree. We may want to change it slightly but it's only a problem for
> people who flip between Maven a repository manager and without but it's to
> ensure the identity of a component. I haven't seen a huge number of
> complaints. I do not want to turn this off. Improve it, sure, but turning
> it off by default I believe is not the right thing to do.
>
>
How about turning it into a warning by default and only fail if you enable
some meaningful option (or implicitly in some plugins such as the release
plugin).

But I must admit that I don't really have a use case in mind where failing
is crucial.



> >  2/ change the error message when this control is activated to clearly
> > explain that the problem comes from the unavailability of the artifact on
> > its original remote repo.
> >
> >  For me 1/ is mandatory and 2/ a nice to have
> >
> > WDYT ?
> >
> >
> > On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <olamy@apache.org<javascript:;>>
> wrote:
> >
> >> I have pushed a fix for that.
> >> Now you can desactivate the enhanced local repository using:
> >> * new cli option: -slrm,--simple-local-repository-manager
> >> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
> >>
> >> will be available for testing here
> >> https://builds.apache.org/job/maven-3.x/ with build #368
> >>
> >>
> >> 2013/1/31 Jörg Hohwiller <joerg@j-hohwiller.de <javascript:;>>:
> >>> Hi Arnaud,
> >>>
> >>>> +1 to consider the current behavior as a bug.
> >>>> We should be able to deactivate it easily (and perhaps to have it off
> by
> >>>> default to activate it only on CI servers)
> >>>
> >>> :)
> >>>
> >>>> and we should take care to have
> >>>> a real error message explaining the issue and not a classical
> dependency
> >>>> not found while the artifact is in the local repo.
> >>>
> >>> This is exactly filed here:
> >>> http://jira.codehaus.org/browse/MNG-5185
> >>>
> >>>>
> >>>> Arnaud
> >>> Cheers
> >>>  Jörg
> >>>
> >>> --
> >>> If know-how becomes know-where, then knowledge gets nowhere.
> >>>  [Jörg Hohwiller]
> >>>
> >>
> >>
> >>
> >> --
> >> Olivier Lamy
> >> Talend: http://coders.talend.com
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> >> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >>
> >>
> >
> >
> > --
> > -----
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Our achievements speak for themselves. What we have to keep track
> of are our failures, discouragements and doubts. We tend to forget
> the past difficulties, the many false starts, and the painful
> groping. We see our past achievements as the end result of a
> clean forward thrust, and our present difficulties as
> signs of decline and decay.
>
>  -- Eric Hoffer, Reflections on the Human Condition
>
>
>
>
>
>

Re: Pain with MNG-5181 (_maven.repositories)

[Jason van Zyl <ja...@tesla.io>]

Cool, fair enough.

On Feb 3, 2013, at 7:31 PM, Hervé BOUTEMY <he...@free.fr> wrote:

> a question of compromise: I just added a warning message to let users know 
> they should avoid the option
> 
> Regards,
> 
> Hervé
> 
> Le dimanche 3 février 2013 13:37:13 Jason van Zyl a écrit :
>> On Feb 3, 2013, at 1:14 PM, Hervé BOUTEMY <he...@free.fr> wrote:
>>> Le dimanche 3 février 2013 11:14:03 Jason van Zyl a écrit :
>>>> I do not see what value there is in even allowing this feature to be
>>>> turned
>>>> off ever. It can only cause inconsistencies.
>>> 
>>> please read back the initial user complaining
>>> turning this feature off is just getting Maven 2 behaviour, even if it's
>>> not the best solution
>> 
>> Maven 2 to 3 was the time to change behaviour to a more sane approach. Just
>> because a user wants something that's broken doesn't mean we should put it
>> back. This behaviour disabled overall is a net negative. There is no normal
>> workflow in a users day where disabling this is beneficial.
>>>> What Maven 2.x does is wrong because it can lead to "works for me" while
>>>> not working for anyone else.
>>> 
>>> we're in perfect sync
>>> if the error meessage was clear about a solution, and gave a link to a
>>> good
>>> documentation about the possible causes and real fixes, we could avoid
>>> this flag> 
>>>> Why is it a good thing to let people believe they have something that
>>>> works
>>>> when it doesn't work for anyone else? This is what you'll get turning
>>>> this
>>>> off.
>>> 
>>> it is good because Maven 3 behaves like Maven 2 (even if default Maven 3
>>> behaviour is better)
>> 
>> I disagree. The benefit of consistent behaviour across versions is dwarfed
>> by the greater confusion caused by a build working in one place and not
>> another. The artifact they require is not remotely accessible, I don't see
>> under any condition this should not fail.
>> 
>> I agree a full description of the feature can pop up to tell the user why. I
>> honestly still don't understand the issue Arnaud is having.
>>>> I'm looking at the JIRA and Arnaud's explanation with the staging feature
>>>> and I think it just needs to be configured correctly. I have never had
>>>> that
>>>> problem with Nexus as a staging repository is automatically added to the
>>>> group according to the staging profile and therefore the same URL for the
>>>> group works consistently. I'm not sure why you would use a profile to get
>>>> at staging repositories as you should let the repository manager deal
>>>> with
>>>> that as Robert points out in the second comment. Arnaud, I'm not sure
>>>> this
>>>> feature actually solves your real problem.
>>> 
>>> we all know this feature does not solve the real problem: yes, it's only a
>>> workaround
>> 
>> I honestly don't think it's a problem. It stops someone from being able
>> build when the artifact is not available remotely. For someone who only
>> ever uses Central and no mirrors this is never going to be a problem. For
>> people  who are moving in and out of organizations where they are doing
>> work, the build should fail if no one else in the organization can get to
>> the artifact. I just do not see how, in any way, it makes sense to make it
>> possible for an individual to have a different behaviour then everyone else
>> in an organization. We do so much to ensure this and this change in
>> behaviour is a step forward.
>> 
>> For the case where someone is trying to build an offline portable
>> repository, well this is just not what Maven does and optimizing for that
>> use case is not important IMO. I can think of a number of ways to create a
>> portable repository of artifacts without requiring the disablement of
>> consistency.
>>>>>> And I'm
>>>>>> frankly tired of slapdash changes like this being made in the core
>>>>>> without
>>>>>> any discussion or review.
>>>>> 
>>>>> which change are you talking about? enhanced local repository without
>>>>> really understanding or documentation, or the addition of -slrm option
>>>>> as
>>>>> a reasonable fix for MNG-5181, ie add an option to disable the enhanced
>>>>> local repository manager?
>>>> 
>>>> Benjamin's changes are never slapdash, I'm referring to Olivier's
>>>> changes.
>>> 
>>> ask users if this feature is slapdash, and IMHO they will more likely say
>>> "finally".
>>> Of course, if we had a better alternative, it would be even better
>> 
>> I doubt it. These will be users who don't know what they are doing. Just
>> because a user asks for something doesn't mean you should give it to them.
>> Especially if you don't understand what the feature is intended to do. That
>> there is no documentation is no excuse. Read the code or ask someone.
>>>> I think Arnaud's case probably can be solved with a bit of
>>>> re-configuration
>>>> in Nexus. Most of the users complaining either don't care about
>>>> organizational consistency and are just building for themselves, or are
>>>> trying to build offline repositories which is not Maven's primary
>>>> concern.
>>> 
>>> and the fact is that current error message doesn't help them understand
>>> what they are doing wrong, then help them fix it
>> 
>> So I would agree that putting the feature explanation there would have been
>> wiser than disabling the feature. Ignoring the explanation of the features
>> benefit and potentially causing a number of more harmful situations isn't
>> the right way to do it.
>>>> I don't see why you would ever disable this. It covers up other problems
>>>> you have and just creates more issues.
>>> 
>>> no, it does not create more issues than Maven 2
>> 
>> So why is that good? I agree that within a major version you mimic
>> sub-optimal behaviour for the sake of consistency, but moving into Maven 3
>> the goal was improved consistency.
>>>> It currently does the right thing. If an artifact is not resolvable  with
>>>> the current setup you're just masking potential problems.
>>> 
>>> +1
>>> 
>>>> It needs to remain off by default. Most people will never find it and
>>>> likely can't do much harm.
>>> 
>>> +1
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> To do two things at once is to do neither.
>> 
>> -- Publilius Syrus, Roman slave, first century B.C.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. 

 -- Paul Graham

Re: Pain with MNG-5181 (_maven.repositories)

[Hervé BOUTEMY <he...@free.fr>]

a question of compromise: I just added a warning message to let users know 
they should avoid the option

Regards,

Hervé

Le dimanche 3 février 2013 13:37:13 Jason van Zyl a écrit :
> On Feb 3, 2013, at 1:14 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> > Le dimanche 3 février 2013 11:14:03 Jason van Zyl a écrit :
> >> I do not see what value there is in even allowing this feature to be
> >> turned
> >> off ever. It can only cause inconsistencies.
> > 
> > please read back the initial user complaining
> > turning this feature off is just getting Maven 2 behaviour, even if it's
> > not the best solution
> 
> Maven 2 to 3 was the time to change behaviour to a more sane approach. Just
> because a user wants something that's broken doesn't mean we should put it
> back. This behaviour disabled overall is a net negative. There is no normal
> workflow in a users day where disabling this is beneficial.
> >> What Maven 2.x does is wrong because it can lead to "works for me" while
> >> not working for anyone else.
> > 
> > we're in perfect sync
> > if the error meessage was clear about a solution, and gave a link to a
> > good
> > documentation about the possible causes and real fixes, we could avoid
> > this flag> 
> >> Why is it a good thing to let people believe they have something that
> >> works
> >> when it doesn't work for anyone else? This is what you'll get turning
> >> this
> >> off.
> > 
> > it is good because Maven 3 behaves like Maven 2 (even if default Maven 3
> > behaviour is better)
> 
> I disagree. The benefit of consistent behaviour across versions is dwarfed
> by the greater confusion caused by a build working in one place and not
> another. The artifact they require is not remotely accessible, I don't see
> under any condition this should not fail.
> 
> I agree a full description of the feature can pop up to tell the user why. I
> honestly still don't understand the issue Arnaud is having.
> >> I'm looking at the JIRA and Arnaud's explanation with the staging feature
> >> and I think it just needs to be configured correctly. I have never had
> >> that
> >> problem with Nexus as a staging repository is automatically added to the
> >> group according to the staging profile and therefore the same URL for the
> >> group works consistently. I'm not sure why you would use a profile to get
> >> at staging repositories as you should let the repository manager deal
> >> with
> >> that as Robert points out in the second comment. Arnaud, I'm not sure
> >> this
> >> feature actually solves your real problem.
> > 
> > we all know this feature does not solve the real problem: yes, it's only a
> > workaround
> 
> I honestly don't think it's a problem. It stops someone from being able
> build when the artifact is not available remotely. For someone who only
> ever uses Central and no mirrors this is never going to be a problem. For
> people  who are moving in and out of organizations where they are doing
> work, the build should fail if no one else in the organization can get to
> the artifact. I just do not see how, in any way, it makes sense to make it
> possible for an individual to have a different behaviour then everyone else
> in an organization. We do so much to ensure this and this change in
> behaviour is a step forward.
> 
> For the case where someone is trying to build an offline portable
> repository, well this is just not what Maven does and optimizing for that
> use case is not important IMO. I can think of a number of ways to create a
> portable repository of artifacts without requiring the disablement of
> consistency.
> >>>> And I'm
> >>>> frankly tired of slapdash changes like this being made in the core
> >>>> without
> >>>> any discussion or review.
> >>> 
> >>> which change are you talking about? enhanced local repository without
> >>> really understanding or documentation, or the addition of -slrm option
> >>> as
> >>> a reasonable fix for MNG-5181, ie add an option to disable the enhanced
> >>> local repository manager?
> >> 
> >> Benjamin's changes are never slapdash, I'm referring to Olivier's
> >> changes.
> > 
> > ask users if this feature is slapdash, and IMHO they will more likely say
> > "finally".
> > Of course, if we had a better alternative, it would be even better
> 
> I doubt it. These will be users who don't know what they are doing. Just
> because a user asks for something doesn't mean you should give it to them.
> Especially if you don't understand what the feature is intended to do. That
> there is no documentation is no excuse. Read the code or ask someone.
> >> I think Arnaud's case probably can be solved with a bit of
> >> re-configuration
> >> in Nexus. Most of the users complaining either don't care about
> >> organizational consistency and are just building for themselves, or are
> >> trying to build offline repositories which is not Maven's primary
> >> concern.
> > 
> > and the fact is that current error message doesn't help them understand
> > what they are doing wrong, then help them fix it
> 
> So I would agree that putting the feature explanation there would have been
> wiser than disabling the feature. Ignoring the explanation of the features
> benefit and potentially causing a number of more harmful situations isn't
> the right way to do it.
> >> I don't see why you would ever disable this. It covers up other problems
> >> you have and just creates more issues.
> > 
> > no, it does not create more issues than Maven 2
> 
> So why is that good? I agree that within a major version you mimic
> sub-optimal behaviour for the sake of consistency, but moving into Maven 3
> the goal was improved consistency.
> >> It currently does the right thing. If an artifact is not resolvable  with
> >> the current setup you're just masking potential problems.
> > 
> > +1
> > 
> >> It needs to remain off by default. Most people will never find it and
> >> likely can't do much harm.
> > 
> > +1
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> 
> Thanks,
> 
> Jason
> 
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
> 
> To do two things at once is to do neither.
> 
>  -- Publilius Syrus, Roman slave, first century B.C.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Pain with MNG-5181 (_maven.repositories)

[Jason van Zyl <ja...@tesla.io>]

On Feb 3, 2013, at 1:14 PM, Hervé BOUTEMY <he...@free.fr> wrote:

> Le dimanche 3 février 2013 11:14:03 Jason van Zyl a écrit :
>> I do not see what value there is in even allowing this feature to be turned
>> off ever. It can only cause inconsistencies.
> please read back the initial user complaining
> turning this feature off is just getting Maven 2 behaviour, even if it's not 
> the best solution
> 

Maven 2 to 3 was the time to change behaviour to a more sane approach. Just because a user wants something that's broken doesn't mean we should put it back. This behaviour disabled overall is a net negative. There is no normal workflow in a users day where disabling this is beneficial.

>> What Maven 2.x does is wrong because it can lead to "works for me" while not
>> working for anyone else.
> we're in perfect sync
> if the error meessage was clear about a solution, and gave a link to a good 
> documentation about the possible causes and real fixes, we could avoid this flag
> 
>> Why is it a good thing to let people believe they have something that works
>> when it doesn't work for anyone else? This is what you'll get turning this
>> off.
> it is good because Maven 3 behaves like Maven 2 (even if default Maven 3 
> behaviour is better)

I disagree. The benefit of consistent behaviour across versions is dwarfed by the greater confusion caused by a build working in one place and not another. The artifact they require is not remotely accessible, I don't see under any condition this should not fail.

I agree a full description of the feature can pop up to tell the user why. I honestly still don't understand the issue Arnaud is having.

> 
>> I'm looking at the JIRA and Arnaud's explanation with the staging feature
>> and I think it just needs to be configured correctly. I have never had that
>> problem with Nexus as a staging repository is automatically added to the
>> group according to the staging profile and therefore the same URL for the
>> group works consistently. I'm not sure why you would use a profile to get
>> at staging repositories as you should let the repository manager deal with
>> that as Robert points out in the second comment. Arnaud, I'm not sure this
>> feature actually solves your real problem.
> we all know this feature does not solve the real problem: yes, it's only a 
> workaround
> 

I honestly don't think it's a problem. It stops someone from being able build when the artifact is not available remotely. For someone who only ever uses Central and no mirrors this is never going to be a problem. For people  who are moving in and out of organizations where they are doing work, the build should fail if no one else in the organization can get to the artifact. I just do not see how, in any way, it makes sense to make it possible for an individual to have a different behaviour then everyone else in an organization. We do so much to ensure this and this change in behaviour is a step forward.

For the case where someone is trying to build an offline portable repository, well this is just not what Maven does and optimizing for that use case is not important IMO. I can think of a number of ways to create a portable repository of artifacts without requiring the disablement of consistency.

>>>> And I'm
>>>> frankly tired of slapdash changes like this being made in the core
>>>> without
>>>> any discussion or review.
>>> 
>>> which change are you talking about? enhanced local repository without
>>> really understanding or documentation, or the addition of -slrm option as
>>> a reasonable fix for MNG-5181, ie add an option to disable the enhanced
>>> local repository manager?
>> 
>> Benjamin's changes are never slapdash, I'm referring to Olivier's changes.
> ask users if this feature is slapdash, and IMHO they will more likely say 
> "finally".
> Of course, if we had a better alternative, it would be even better
> 

I doubt it. These will be users who don't know what they are doing. Just because a user asks for something doesn't mean you should give it to them. Especially if you don't understand what the feature is intended to do. That there is no documentation is no excuse. Read the code or ask someone.

>> I think Arnaud's case probably can be solved with a bit of re-configuration
>> in Nexus. Most of the users complaining either don't care about
>> organizational consistency and are just building for themselves, or are
>> trying to build offline repositories which is not Maven's primary concern.
> and the fact is that current error message doesn't help them understand what 
> they are doing wrong, then help them fix it
> 

So I would agree that putting the feature explanation there would have been wiser than disabling the feature. Ignoring the explanation of the features benefit and potentially causing a number of more harmful situations isn't the right way to do it.

>> I don't see why you would ever disable this. It covers up other problems you
>> have and just creates more issues.
> no, it does not create more issues than Maven 2
> 

So why is that good? I agree that within a major version you mimic sub-optimal behaviour for the sake of consistency, but moving into Maven 3 the goal was improved consistency.

>> It currently does the right thing. If an artifact is not resolvable  with
>> the current setup you're just masking potential problems.
> +1
> 
>> It needs to remain off by default. Most people will never find it and likely
>> can't do much harm.
> +1
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

To do two things at once is to do neither.
 
 -- Publilius Syrus, Roman slave, first century B.C.

Re: Pain with MNG-5181 (_maven.repositories)

[Hervé BOUTEMY <he...@free.fr>]

Le dimanche 3 février 2013 11:14:03 Jason van Zyl a écrit :
> I do not see what value there is in even allowing this feature to be turned
> off ever. It can only cause inconsistencies.
please read back the initial user complaining
turning this feature off is just getting Maven 2 behaviour, even if it's not 
the best solution

> What Maven 2.x does is wrong because it can lead to "works for me" while not
> working for anyone else.
we're in perfect sync
if the error meessage was clear about a solution, and gave a link to a good 
documentation about the possible causes and real fixes, we could avoid this flag

> Why is it a good thing to let people believe they have something that works
> when it doesn't work for anyone else? This is what you'll get turning this
> off.
it is good because Maven 3 behaves like Maven 2 (even if default Maven 3 
behaviour is better)

> I'm looking at the JIRA and Arnaud's explanation with the staging feature
> and I think it just needs to be configured correctly. I have never had that
> problem with Nexus as a staging repository is automatically added to the
> group according to the staging profile and therefore the same URL for the
> group works consistently. I'm not sure why you would use a profile to get
> at staging repositories as you should let the repository manager deal with
> that as Robert points out in the second comment. Arnaud, I'm not sure this
> feature actually solves your real problem.
we all know this feature does not solve the real problem: yes, it's only a 
workaround

> >> And I'm
> >> frankly tired of slapdash changes like this being made in the core
> >> without
> >> any discussion or review.
> > 
> > which change are you talking about? enhanced local repository without
> > really understanding or documentation, or the addition of -slrm option as
> > a reasonable fix for MNG-5181, ie add an option to disable the enhanced
> > local repository manager?
> 
> Benjamin's changes are never slapdash, I'm referring to Olivier's changes.
ask users if this feature is slapdash, and IMHO they will more likely say 
"finally".
Of course, if we had a better alternative, it would be even better

> I think Arnaud's case probably can be solved with a bit of re-configuration
> in Nexus. Most of the users complaining either don't care about
> organizational consistency and are just building for themselves, or are
> trying to build offline repositories which is not Maven's primary concern.
and the fact is that current error message doesn't help them understand what 
they are doing wrong, then help them fix it

> I don't see why you would ever disable this. It covers up other problems you
> have and just creates more issues.
no, it does not create more issues than Maven 2

> It currently does the right thing. If an artifact is not resolvable  with
> the current setup you're just masking potential problems.
+1

> It needs to remain off by default. Most people will never find it and likely
> can't do much harm.
+1


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Pain with MNG-5181 (_maven.repositories)

[Jason van Zyl <ja...@tesla.io>]

On Feb 3, 2013, at 4:12 AM, Hervé BOUTEMY <he...@free.fr> wrote:

> Le samedi 2 février 2013 22:39:55 Jason van Zyl a écrit :
>> On Feb 1, 2013, at 3:47 AM, Arnaud Héritier <ah...@gmail.com> wrote:
>>> My position was to propose the low cost possible solution to have a quick
>>> fix and not to wait for months.
>> 
>> You realize that disabling this feature allows the potential for a developer
>> to go home, download something in a build with a GAV and go to work where
>> that GAV doesn't correspond to the same thing for whatever reason -- and he
>> will never know or be warned with it disabled. Maybe the JAR is patched and
>> not renamed but does something important for the organization like fix a
>> security problem. This might cause a disparity in how the build behaves in
>> a mild case where he sees something different than the other developers.
>> Worst case is that artifact finds its way into something it's not supposed
>> to and cause a real problem.
> is it really a part of the feature? I didn't understand that this feature 
> calculated something like a checksum of an artifact and could store the 
> artifact multiple times
> 
> I thought it was only to avoid for example downloading a dependency from a 
> plugin then use it in component dependency (ie the use case I was expecting): 
> that's what I understanding when reading aether-impl's 
> EnhancedLocalRepositoryManager javadoc and source (in source, since this class 
> is package private, then not published in javadoc)
> 
> Am I wrong? Do I miss something?
> 

h1. Enhanced Remote Repository Support

The feature verifies that the remote repositories configured for the current build can be used to successfully resolve the artifact in question. If you retrieved an artifact in the past from Central and now changed your build to only know about Nexus and it doesn't have any knowledge of that artifact then the build is going to fail. Put differently, if you purged your local repo, your build won't work either. Neglecting offline mode, the goal is to ensure that the resolution works if it could be performed using a clean local repo with the current configuration. Giving confidence that co-workers can reproduce the build and not depend on some artifact magically being pulled down into your local repository in the past which is nowhere to be found in the configured remote repository.

---

So the upshot is that with this feature off  you will happily build all day, but when you commit your CI will fail and anyone you're working with will also get failures because the artifact is not available in your shared setup. I have identity management in my code but the base feature as it exists in Maven asserts the availability of the artifact with the given repository setup.

I do not see what value there is in even allowing this feature to be turned off ever. It can only cause inconsistencies.

> 
>> 
>> Maven currently does not consider the same GAV from two different sources to
>> be the same and for good reason. If we added the logic which asserted they
>> were, in fact, the same JAR like checking the SHA1 I think that would be
>> perfectly reasonable. Turning it off is just not wise.
> Turning it off is just a workaround to get the same behaviour than Maven 2, 
> which is not perfect but that everybody understand, to help people while we're 
> working to understand the feature ourselves (yes, ourselves...) and document 
> it sufficiently for end-users

What Maven 2.x does is wrong because it can lead to "works for me" while not working for anyone else.

> 
>> 
>> If you move around between work and home a lot use a repository manager
>> locally. I've done that forever and I don't have any issues aside from
>> having to add the odd proxy repository when there is a repository listed in
>> a POM. I don't consider it a problem and it prevents the problem of
>> mismatched identity. This logic should be improved not neutered.
> +1 but if we can't improve it before the next release, disabling it can be a 
> temporary solution since this feature is really hard for users
> 

Why is it a good thing to let people believe they have something that works when it doesn't work for anyone else? This is what you'll get turning this off.

I'm looking at the JIRA and Arnaud's explanation with the staging feature and I think it just needs to be configured correctly. I have never had that problem with Nexus as a staging repository is automatically added to the group according to the staging profile and therefore the same URL for the group works consistently. I'm not sure why you would use a profile to get at staging repositories as you should let the repository manager deal with that as Robert points out in the second comment. Arnaud, I'm not sure this feature actually solves your real problem. The failure occurs when the artifact is not available remotely, why would you let someone carry on? Anyone using the same configuration with a clean local repository will have a build that fails.

This feature protects users, removing this makes it easier to create inconsistencies. 


>> And I'm
>> frankly tired of slapdash changes like this being made in the core without
>> any discussion or review.
> which change are you talking about? enhanced local repository without really 
> understanding or documentation, or the addition of -slrm option as a 
> reasonable fix for MNG-5181, ie add an option to disable the enhanced local 
> repository manager?

Benjamin's changes are never slapdash, I'm referring to Olivier's changes. As per the explanation above the feature where the goal is to attain consistency across a team: I have no qualms with what Benjamin did. He fully understood what he was doing and was an effort to make sure a build works for everyone. If you're saying that no one really understands what the feature is for and yet optionally disabled it, I would say is fairly uninformed.

I think Arnaud's case probably can be solved with a bit of re-configuration in Nexus. Most of the users complaining either don't care about organizational consistency and are just building for themselves, or are trying to build offline repositories which is not Maven's primary concern. There are better ways to achieve creating an offline repository without allowing undesirable behaviour in Maven. Letting anything build in one place where we know it won't work in another is bad. That's the basis of this feature and turning it off just let's people cause harm across a team.

> 
> 
>> The last two major changes I've made I've asked
>> other to review my work which I think now with some other incidents of late
>> that would be wise for all changes to the core.
>> 
>> I'm -1 on disabling this feature by default.
> nice, it isn't disabled by default, Olivier did a nice job to not break 
> anything
> 

I don't see why you would ever disable this. It covers up other problems you have and just creates more issues.

> 
>> Fix it properly, using a
>> property to turn it off is half measure which potentially causes users even
>> more severe problems.
> +1
> I'm trying to find a better way for a long time now, that's why I tried to 
> write maven-aether-provider unit tests as a first step
> but for the moment, I couldn't find a solution: thank you Olivier for finding 
> some workaround, even if not ideal
> if anydoby has a clue on how to solve the problem, please explain (and "just 
> do it" is not an explanation)
> 

It currently does the right thing. If an artifact is not resolvable  with the current setup you're just masking potential problems.

It needs to remain off by default. Most people will never find it and likely can't do much harm. There is no real problem and putting in code without really understanding the issue or what the feature is intended to do is sub-optimal at best.

> 
>>> If it could be fixed/configurable in aether it may be the solution to
>>> follow but I'm not sure about the status of this 3rd party project
>>> (eclipse
>>> migration ...) on which we don't have the hand.
>>> Seriously I helped and lost MANY hours with this problem because it is
>>> hard
>>> to diagnose.
>>> I'm sure that many people abandoned to try to understand and just dropped
>>> their local repo or decided to downgraded to m2 (or to switch to another
>>> tool).
>>> I think we can have a lot of similar feedbacks.
>>> The worst thing is to have another thing that users don't understand (lake
>>> of documentation ? communication ?)
>>> The side effect is that changing a repository id (or mirror id) makes
>>> maven
>>> to re-download all the earth (while we are claiming from the beginning
>>> that
>>> Maven won't never download twice a release).
>>> And when the remote artifact just disappeared it is just a nightmare due
>>> to
>>> the lake of correct logs and this case is easy to have.
>>> For example in my company I have a profile to let people DL artifacts from
>>> staging repositories (thus these are releases). It happened that they
>>> activated it once to test a build and then they rebuild the project
>>> without
>>> the profile (thinking the artifact is in the local repo) and it fails ...
>>> 
>>> Sincerely I think I had my worst headaches with maven due to this bug
>>> 
>>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io> wrote:
>>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>>>>> Hi Olivier,
>>>>> 
>>>>> Thx a lot for the fix. It will help a lot the community.
>>>>> But from my point of view it's perhaps not yet enough.
>>>>> We should :
>>>>> 1/ change the default behavior to deactivate this control which is
>>>>> difficult to understand
>>>> 
>>>> I disagree. We may want to change it slightly but it's only a problem for
>>>> people who flip between Maven a repository manager and without but it's
>>>> to
>>>> ensure the identity of a component. I haven't seen a huge number of
>>>> complaints. I do not want to turn this off. Improve it, sure, but turning
>>>> it off by default I believe is not the right thing to do.
>>>> 
>>>>> 2/ change the error message when this control is activated to clearly
>>>>> explain that the problem comes from the unavailability of the artifact
>>>>> on
>>>>> its original remote repo.
>>>>> 
>>>>> For me 1/ is mandatory and 2/ a nice to have
>>>>> 
>>>>> WDYT ?
>>>>> 
>>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org> wrote:
>>>>>> I have pushed a fix for that.
>>>>>> Now you can desactivate the enhanced local repository using:
>>>>>> * new cli option: -slrm,--simple-local-repository-manager
>>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
>>>>>> 
>>>>>> will be available for testing here
>>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
>>>>>> 
>>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
>>>>>>> Hi Arnaud,
>>>>>>> 
>>>>>>>> +1 to consider the current behavior as a bug.
>>>>>>>> We should be able to deactivate it easily (and perhaps to have it off
>>>> 
>>>> by
>>>> 
>>>>>>>> default to activate it only on CI servers)
>>>>>>>> 
>>>>>>> :)
>>>>>>> :
>>>>>>>> and we should take care to have
>>>>>>>> a real error message explaining the issue and not a classical
>>>> 
>>>> dependency
>>>> 
>>>>>>>> not found while the artifact is in the local repo.
>>>>>>> 
>>>>>>> This is exactly filed here:
>>>>>>> http://jira.codehaus.org/browse/MNG-5185
>>>>>>> 
>>>>>>>> Arnaud
>>>>>>> 
>>>>>>> Cheers
>>>>>>> Jörg
>>>>>>> 
>>>>>>> --
>>>>>>> If know-how becomes know-where, then knowledge gets nowhere.
>>>>>>> [Jörg Hohwiller]
>>>>>> 
>>>>>> --
>>>>>> Olivier Lamy
>>>>>> Talend: http://coders.talend.com
>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>> 
>>>>> --
>>>>> -----
>>>>> Arnaud Héritier
>>>>> http://aheritier.net
>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>> Twitter/Skype : aheritier
>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder & CTO, Sonatype
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>> 
>>>> Our achievements speak for themselves. What we have to keep track
>>>> of are our failures, discouragements and doubts. We tend to forget
>>>> the past difficulties, the many false starts, and the painful
>>>> groping. We see our past achievements as the end result of a
>>>> clean forward thrust, and our present difficulties as
>>>> signs of decline and decay.
>>>> 
>>>> -- Eric Hoffer, Reflections on the Human Condition
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> A party which is not afraid of letting culture,
>> business, and welfare go to ruin completely can
>> be omnipotent for a while.
>> 
>>  -- Jakob Burckhardt
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. 

 -- Paul Graham

Re: Pain with MNG-5181 (_maven.repositories)

[Hervé BOUTEMY <he...@free.fr>]

Le samedi 2 février 2013 22:39:55 Jason van Zyl a écrit :
> On Feb 1, 2013, at 3:47 AM, Arnaud Héritier <ah...@gmail.com> wrote:
> > My position was to propose the low cost possible solution to have a quick
> > fix and not to wait for months.
> 
> You realize that disabling this feature allows the potential for a developer
> to go home, download something in a build with a GAV and go to work where
> that GAV doesn't correspond to the same thing for whatever reason -- and he
> will never know or be warned with it disabled. Maybe the JAR is patched and
> not renamed but does something important for the organization like fix a
> security problem. This might cause a disparity in how the build behaves in
> a mild case where he sees something different than the other developers.
> Worst case is that artifact finds its way into something it's not supposed
> to and cause a real problem.
is it really a part of the feature? I didn't understand that this feature 
calculated something like a checksum of an artifact and could store the 
artifact multiple times

I thought it was only to avoid for example downloading a dependency from a 
plugin then use it in component dependency (ie the use case I was expecting): 
that's what I understanding when reading aether-impl's 
EnhancedLocalRepositoryManager javadoc and source (in source, since this class 
is package private, then not published in javadoc)

Am I wrong? Do I miss something?


> 
> Maven currently does not consider the same GAV from two different sources to
> be the same and for good reason. If we added the logic which asserted they
> were, in fact, the same JAR like checking the SHA1 I think that would be
> perfectly reasonable. Turning it off is just not wise.
Turning it off is just a workaround to get the same behaviour than Maven 2, 
which is not perfect but that everybody understand, to help people while we're 
working to understand the feature ourselves (yes, ourselves...) and document 
it sufficiently for end-users

> 
> If you move around between work and home a lot use a repository manager
> locally. I've done that forever and I don't have any issues aside from
> having to add the odd proxy repository when there is a repository listed in
> a POM. I don't consider it a problem and it prevents the problem of
> mismatched identity. This logic should be improved not neutered.
+1 but if we can't improve it before the next release, disabling it can be a 
temporary solution since this feature is really hard for users

> And I'm
> frankly tired of slapdash changes like this being made in the core without
> any discussion or review.
which change are you talking about? enhanced local repository without really 
understanding or documentation, or the addition of -slrm option as a 
reasonable fix for MNG-5181, ie add an option to disable the enhanced local 
repository manager?


> The last two major changes I've made I've asked
> other to review my work which I think now with some other incidents of late
> that would be wise for all changes to the core.
> 
> I'm -1 on disabling this feature by default.
nice, it isn't disabled by default, Olivier did a nice job to not break 
anything


> Fix it properly, using a
> property to turn it off is half measure which potentially causes users even
> more severe problems.
+1
I'm trying to find a better way for a long time now, that's why I tried to 
write maven-aether-provider unit tests as a first step
but for the moment, I couldn't find a solution: thank you Olivier for finding 
some workaround, even if not ideal
if anydoby has a clue on how to solve the problem, please explain (and "just 
do it" is not an explanation)


> > If it could be fixed/configurable in aether it may be the solution to
> > follow but I'm not sure about the status of this 3rd party project
> > (eclipse
> > migration ...) on which we don't have the hand.
> > Seriously I helped and lost MANY hours with this problem because it is
> > hard
> > to diagnose.
> > I'm sure that many people abandoned to try to understand and just dropped
> > their local repo or decided to downgraded to m2 (or to switch to another
> > tool).
> > I think we can have a lot of similar feedbacks.
> > The worst thing is to have another thing that users don't understand (lake
> > of documentation ? communication ?)
> > The side effect is that changing a repository id (or mirror id) makes
> > maven
> > to re-download all the earth (while we are claiming from the beginning
> > that
> > Maven won't never download twice a release).
> > And when the remote artifact just disappeared it is just a nightmare due
> > to
> > the lake of correct logs and this case is easy to have.
> > For example in my company I have a profile to let people DL artifacts from
> > staging repositories (thus these are releases). It happened that they
> > activated it once to test a build and then they rebuild the project
> > without
> > the profile (thinking the artifact is in the local repo) and it fails ...
> > 
> > Sincerely I think I had my worst headaches with maven due to this bug
> > 
> > On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io> wrote:
> >> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com> wrote:
> >>> Hi Olivier,
> >>> 
> >>> Thx a lot for the fix. It will help a lot the community.
> >>> But from my point of view it's perhaps not yet enough.
> >>> We should :
> >>> 1/ change the default behavior to deactivate this control which is
> >>> difficult to understand
> >> 
> >> I disagree. We may want to change it slightly but it's only a problem for
> >> people who flip between Maven a repository manager and without but it's
> >> to
> >> ensure the identity of a component. I haven't seen a huge number of
> >> complaints. I do not want to turn this off. Improve it, sure, but turning
> >> it off by default I believe is not the right thing to do.
> >> 
> >>> 2/ change the error message when this control is activated to clearly
> >>> explain that the problem comes from the unavailability of the artifact
> >>> on
> >>> its original remote repo.
> >>> 
> >>> For me 1/ is mandatory and 2/ a nice to have
> >>> 
> >>> WDYT ?
> >>> 
> >>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org> wrote:
> >>>> I have pushed a fix for that.
> >>>> Now you can desactivate the enhanced local repository using:
> >>>> * new cli option: -slrm,--simple-local-repository-manager
> >>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
> >>>> 
> >>>> will be available for testing here
> >>>> https://builds.apache.org/job/maven-3.x/ with build #368
> >>>> 
> >>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
> >>>>> Hi Arnaud,
> >>>>> 
> >>>>>> +1 to consider the current behavior as a bug.
> >>>>>> We should be able to deactivate it easily (and perhaps to have it off
> >> 
> >> by
> >> 
> >>>>>> default to activate it only on CI servers)
> >>>>>> 
> >>>>> :)
> >>>>> :
> >>>>>> and we should take care to have
> >>>>>> a real error message explaining the issue and not a classical
> >> 
> >> dependency
> >> 
> >>>>>> not found while the artifact is in the local repo.
> >>>>> 
> >>>>> This is exactly filed here:
> >>>>> http://jira.codehaus.org/browse/MNG-5185
> >>>>> 
> >>>>>> Arnaud
> >>>>> 
> >>>>> Cheers
> >>>>> Jörg
> >>>>> 
> >>>>> --
> >>>>> If know-how becomes know-where, then knowledge gets nowhere.
> >>>>> [Jörg Hohwiller]
> >>>> 
> >>>> --
> >>>> Olivier Lamy
> >>>> Talend: http://coders.talend.com
> >>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>> 
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>> 
> >>> --
> >>> -----
> >>> Arnaud Héritier
> >>> http://aheritier.net
> >>> Mail/GTalk: aheritier AT gmail DOT com
> >>> Twitter/Skype : aheritier
> >> 
> >> Thanks,
> >> 
> >> Jason
> >> 
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder & CTO, Sonatype
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >> 
> >> Our achievements speak for themselves. What we have to keep track
> >> of are our failures, discouragements and doubts. We tend to forget
> >> the past difficulties, the many false starts, and the painful
> >> groping. We see our past achievements as the end result of a
> >> clean forward thrust, and our present difficulties as
> >> signs of decline and decay.
> >> 
> >> -- Eric Hoffer, Reflections on the Human Condition
> 
> Thanks,
> 
> Jason
> 
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
> 
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
> 
>   -- Jakob Burckhardt

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Pain with MNG-5181 (_maven.repositories)

[Barrie Treloar <ba...@gmail.com>]

On 11 February 2013 09:31, Jörg Hohwiller <jo...@j-hohwiller.de> wrote:
> I see your point but there is a missmatch between theory and reality.
> 1. Because mirrors of my company have been blacklisted we

How about you fix being "blacklisted" and check this again?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Pain with MNG-5181 (_maven.repositories)

[Jörg Hohwiller <jo...@j-hohwiller.de>]

Hi Jason,

Am 03.02.2013 21:40, schrieb Jason van Zyl:
> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
>
>> +1.
>>
>> Though the feature seems interesting, it should have had its own
>> advertisement while being introduced.
>> Even after re-reading
>> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
>> I'm
>> still unsure about where/when it would bite me.
> Does this make sense to you?
>
> ---
>
> h1. Enhanced Remote Repository Support
>
> The feature verifies that the remote repositories configured for the current build can be used to successfully resolve the artifact in question. If you retrieved an artifact in the past from Central and now changed your build to only know about Nexus and it doesn't have any knowledge of that artifact then the build is going to fail. Put differently, if you purged your local repo, your build won't work either. Neglecting offline mode, the goal is to ensure that the resolution works if it could be performed using a clean local repo with the current configuration. Giving confidence that co-workers can reproduce the build and not depend on some artifact magically being pulled down into your local repository in the past which is nowhere to be found in the configured remote repository.

I see your point but there is a missmatch between theory and reality.
1. Because mirrors of my company have been blacklisted we "forced" every 
employee to use a enterprise maven repo (via <mirrorOf>*</mirrorOf>). 
Swtiching to private projects causes offline builds to fail.

2. Providing internal arftifacts via USB-Stick to collegues that do not 
yet have access to the projects enterpise repo is now not possible 
without deleting _maven.repositories what is causing massive confusion 
and a waste of time and energy. People get really angry about maven and 
want to switch to gradle or builder. I am a fan of maven but I can not 
argue for this "feature".

3. But it gets even worse: Even though OSSRH is performing validation 
there are still new artifacts getting into central that are somehow 
invalid (have a groupid that is not compatible to the path in the 
repository). Downloading directly from central works anyways but NOT via 
artifactory that we are using because of the blacklisting. Now some 
developers did not use mirrorOf but added artifactory as additional repo 
and used an other proxy with an IP that is not blacklisted. They had no 
problems but others that followed the official policy failed to build 
because even if they had the artifact in local repo it could NOT be 
downloaded again via artficatory.

>
> ---
>
> And would you want that off by default?
>

IMHO Yes.

Cheers
   Jörg

Re: Pain with MNG-5181 (_maven.repositories)

[Jason van Zyl <ja...@tesla.io>]

Cool, much appreciated. I'll take a look.

On Feb 3, 2013, at 5:15 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:

> here it is https://gist.github.com/c07256a99d3b2af322eb
> 
> @home i remove the settings.xml in general
> 
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
> 
> 
> 
> 2013/2/3 Jason van Zyl <ja...@tesla.io>
> 
>> Would still be useful if you removed your passwords and sent me both
>> configurations, if this is happening to you with this configuration it's
>> probably happening to others. If I can give it a quick look I can probably
>> tell you why the error is happening or determine if it is, in fact, a bug.
>> 
>> On Feb 3, 2013, at 5:04 PM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>> 
>>> well nothing special in it (host/port/protocol proxies +
>> username/password
>>> servers).
>>> 
>>> however i build company projects using enterprise project having as
>>> dependencies tomee, could it generate it?
>>> 
>>> 
>>> *Romain Manni-Bucau*
>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>>> *Blog: **http://rmannibucau.wordpress.com/*<
>> http://rmannibucau.wordpress.com/>
>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>> *Github: https://github.com/rmannibucau*
>>> 
>>> 
>>> 
>>> 2013/2/3 Jason van Zyl <ja...@tesla.io>
>>> 
>>>> Can you send me the configurations?
>>>> 
>>>> If the artifacts are accessible and it fails then that's a bug. But I am
>>>> willing to bet one configuration yields a different set of URLs to which
>>>> particular artifacts are not accessible. If I can reproduce it then this
>>>> will help contribute to an error message that's more useful.
>>>> 
>>>> On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau <rm...@gmail.com>
>>>> wrote:
>>>> 
>>>>> I switch my settings and the only differences are:
>>>>> 
>>>>> 1) some server config (i guess that's not important)
>>>>> 2) (more important) proxies (host/port)
>>>>> 
>>>>> i don't use mirrorOf.
>>>>> 
>>>>> PS: the issue can happen with tomee trunk so repos are always available
>>>>> since the internet is available.
>>>>> 
>>>>> *Romain Manni-Bucau*
>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>>>>> *Blog: **http://rmannibucau.wordpress.com/*<
>>>> http://rmannibucau.wordpress.com/>
>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>>>> *Github: https://github.com/rmannibucau*
>>>>> 
>>>>> 
>>>>> 
>>>>> 2013/2/3 Jason van Zyl <ja...@tesla.io>
>>>>> 
>>>>>> If this is on one machine where you are not changing configurations or
>>>>>> locations then something else is wrong as this does not happen for a
>>>>>> machine that stays in the same place using the same settings.xml. Do
>> you
>>>>>> use a mirrorOf in your settings.xml that points to a group repository?
>>>> Can
>>>>>> you share your configuration? When you encounter this problem next,
>> move
>>>>>> your whole local repository out of the way (or use
>>>>>> -Dmaven.repo.local=/tmp/repo) and you find that the build will fail.
>>>>>> 
>>>>>> When this error occurs it means that the artifacts you're asking for
>> are
>>>>>> not available in any configured repository. You erase
>>>> _maven.repositories
>>>>>> file, and Maven does not verify that artifact's existence in the
>> remote
>>>>>> repository and let's you use the artifact you acquired locally by some
>>>>>> other means.
>>>>>> 
>>>>>> This generally happens as a result of switching between configurations
>>>>>> which changes the id/url of the repository you are using. You do a
>> build
>>>>>> against id=repo1(URL1) and get some artifacts and those are recorded
>> in
>>>> the
>>>>>> _maven.repositories files, and then you switch configurations and use
>>>>>> id=repo2(URL2) and that repository doesn't have the artifacts you
>>>> acquired
>>>>>> from id=repo1(URL1).
>>>>>> 
>>>>>> The problem encountered for people flipping between using Central
>>>> directly
>>>>>> and using a mirrorOf setting with a repository manager is as follows:
>>>>>> 
>>>>>> If you have no mirrorOf setting and you have POMs that contain
>>>> repository
>>>>>> entries Maven will follow the repositories in the POMs and acquire any
>>>>>> dependencies from those repositories listed in the POMs. Now when you
>>>> flip
>>>>>> to using a mirrorOf setting with a repository manager all those
>> requests
>>>>>> will be routed through that single URL. If you have not setup the
>>>> proxies
>>>>>> in your repository manager that correspond to the repositories in the
>>>> POMs
>>>>>> the build will fail because those artifacts are not accessible to the
>>>>>> repository manager.
>>>>>> 
>>>>>> On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau <rmannibucau@gmail.com
>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi guys,
>>>>>>> 
>>>>>>> Not sure it is linked or not (i read the thread lately) but at work
>> we
>>>>>> use
>>>>>>> a proxy and not at "home" and i often have to remove _maven.repo
>> files
>>>>>>> (both ways) to make my build work again...that's an everyday pain.
>>>>>>> Le 3 févr. 2013 21:41, "Jason van Zyl" <ja...@tesla.io> a écrit :
>>>>>>> 
>>>>>>>> 
>>>>>>>> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
>>>>>>>> 
>>>>>>>>> +1.
>>>>>>>>> 
>>>>>>>>> Though the feature seems interesting, it should have had its own
>>>>>>>>> advertisement while being introduced.
>>>>>>>>> Even after re-reading
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
>>>>>>>>> I'm
>>>>>>>>> still unsure about where/when it would bite me.
>>>>>>>> 
>>>>>>>> Does this make sense to you?
>>>>>>>> 
>>>>>>>> ---
>>>>>>>> 
>>>>>>>> h1. Enhanced Remote Repository Support
>>>>>>>> 
>>>>>>>> The feature verifies that the remote repositories configured for the
>>>>>>>> current build can be used to successfully resolve the artifact in
>>>>>> question.
>>>>>>>> If you retrieved an artifact in the past from Central and now
>> changed
>>>>>> your
>>>>>>>> build to only know about Nexus and it doesn't have any knowledge of
>>>> that
>>>>>>>> artifact then the build is going to fail. Put differently, if you
>>>> purged
>>>>>>>> your local repo, your build won't work either. Neglecting offline
>>>> mode,
>>>>>> the
>>>>>>>> goal is to ensure that the resolution works if it could be performed
>>>>>> using
>>>>>>>> a clean local repo with the current configuration. Giving confidence
>>>>>> that
>>>>>>>> co-workers can reproduce the build and not depend on some artifact
>>>>>>>> magically being pulled down into your local repository in the past
>>>>>> which is
>>>>>>>> nowhere to be found in the configured remote repository.
>>>>>>>> 
>>>>>>>> ---
>>>>>>>> 
>>>>>>>> And would you want that off by default?
>>>>>>>> 
>>>>>>>>> As I know and like Maven quite well, if I was bitten by that, I
>> might
>>>>>> do
>>>>>>>>> some reseach and find jiras etc.
>>>>>>>>> 
>>>>>>>>> Others might just struggle to make it work and grow the maven
>> bashing
>>>>>>>> group
>>>>>>>>> as Jeff said.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2013/2/1 Jeff MAURY <je...@jeffmaury.com>
>>>>>>>>> 
>>>>>>>>>> +1 on Arnaud's comments.
>>>>>>>>>> The main problem with this "feature" is that it is not documented
>>>>>> thus I
>>>>>>>>>> can't explain the real reason why Maven download several times
>>>>>> released
>>>>>>>>>> artifacts and this causes members of the Maven bashing group to
>> grow
>>>>>>>>>> 
>>>>>>>>>> Jeff
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <
>>>> aheritier@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> My position was to propose the low cost possible solution to
>> have a
>>>>>>>> quick
>>>>>>>>>>> fix and not to wait for months.
>>>>>>>>>>> If it could be fixed/configurable in aether it may be the
>> solution
>>>> to
>>>>>>>>>>> follow but I'm not sure about the status of this 3rd party
>> project
>>>>>>>>>> (eclipse
>>>>>>>>>>> migration ...) on which we don't have the hand.
>>>>>>>>>>> Seriously I helped and lost MANY hours with this problem because
>> it
>>>>>> is
>>>>>>>>>> hard
>>>>>>>>>>> to diagnose.
>>>>>>>>>>> I'm sure that many people abandoned to try to understand and just
>>>>>>>> dropped
>>>>>>>>>>> their local repo or decided to downgraded to m2 (or to switch to
>>>>>>>> another
>>>>>>>>>>> tool).
>>>>>>>>>>> I think we can have a lot of similar feedbacks.
>>>>>>>>>>> The worst thing is to have another thing that users don't
>>>> understand
>>>>>>>>>> (lake
>>>>>>>>>>> of documentation ? communication ?)
>>>>>>>>>>> The side effect is that changing a repository id (or mirror id)
>>>> makes
>>>>>>>>>> maven
>>>>>>>>>>> to re-download all the earth (while we are claiming from the
>>>>>> beginning
>>>>>>>>>> that
>>>>>>>>>>> Maven won't never download twice a release).
>>>>>>>>>>> And when the remote artifact just disappeared it is just a
>>>> nightmare
>>>>>>>> due
>>>>>>>>>> to
>>>>>>>>>>> the lake of correct logs and this case is easy to have.
>>>>>>>>>>> For example in my company I have a profile to let people DL
>>>> artifacts
>>>>>>>>>> from
>>>>>>>>>>> staging repositories (thus these are releases). It happened that
>>>> they
>>>>>>>>>>> activated it once to test a build and then they rebuild the
>> project
>>>>>>>>>> without
>>>>>>>>>>> the profile (thinking the artifact is in the local repo) and it
>>>> fails
>>>>>>>> ...
>>>>>>>>>>> 
>>>>>>>>>>> Sincerely I think I had my worst headaches with maven due to this
>>>> bug
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io>
>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <
>> aheritier@gmail.com
>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Olivier,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thx a lot for the fix. It will help a lot the community.
>>>>>>>>>>>>> But from my point of view it's perhaps not yet enough.
>>>>>>>>>>>>> We should :
>>>>>>>>>>>>> 1/ change the default behavior to deactivate this control which
>>>> is
>>>>>>>>>>>>> difficult to understand
>>>>>>>>>>>> 
>>>>>>>>>>>> I disagree. We may want to change it slightly but it's only a
>>>>>> problem
>>>>>>>>>> for
>>>>>>>>>>>> people who flip between Maven a repository manager and without
>> but
>>>>>>>> it's
>>>>>>>>>>> to
>>>>>>>>>>>> ensure the identity of a component. I haven't seen a huge number
>>>> of
>>>>>>>>>>>> complaints. I do not want to turn this off. Improve it, sure,
>> but
>>>>>>>>>> turning
>>>>>>>>>>>> it off by default I believe is not the right thing to do.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 2/ change the error message when this control is activated to
>>>>>>>>>> clearly
>>>>>>>>>>>>> explain that the problem comes from the unavailability of the
>>>>>>>>>> artifact
>>>>>>>>>>> on
>>>>>>>>>>>>> its original remote repo.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> For me 1/ is mandatory and 2/ a nice to have
>>>>>>>>>>>>> 
>>>>>>>>>>>>> WDYT ?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <
>> olamy@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I have pushed a fix for that.
>>>>>>>>>>>>>> Now you can desactivate the enhanced local repository using:
>>>>>>>>>>>>>> * new cli option: -slrm,--simple-local-repository-manager
>>>>>>>>>>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> will be available for testing here
>>>>>>>>>>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
>>>>>>>>>>>>>>> Hi Arnaud,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> +1 to consider the current behavior as a bug.
>>>>>>>>>>>>>>>> We should be able to deactivate it easily (and perhaps to
>> have
>>>>>> it
>>>>>>>>>>> off
>>>>>>>>>>>> by
>>>>>>>>>>>>>>>> default to activate it only on CI servers)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> and we should take care to have
>>>>>>>>>>>>>>>> a real error message explaining the issue and not a
>> classical
>>>>>>>>>>>> dependency
>>>>>>>>>>>>>>>> not found while the artifact is in the local repo.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> This is exactly filed here:
>>>>>>>>>>>>>>> http://jira.codehaus.org/browse/MNG-5185
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Arnaud
>>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>>> Jörg
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> If know-how becomes know-where, then knowledge gets nowhere.
>>>>>>>>>>>>>>> [Jörg Hohwiller]
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Olivier Lamy
>>>>>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> -----
>>>>>>>>>>>>> Arnaud Héritier
>>>>>>>>>>>>> http://aheritier.net
>>>>>>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>>>>>>>> Twitter/Skype : aheritier
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> 
>>>>>>>>>>>> Jason
>>>>>>>>>>>> 
>>>>>>>>>>>> ----------------------------------------------------------
>>>>>>>>>>>> Jason van Zyl
>>>>>>>>>>>> Founder & CTO, Sonatype
>>>>>>>>>>>> Founder,  Apache Maven
>>>>>>>>>>>> http://twitter.com/jvanzyl
>>>>>>>>>>>> ---------------------------------------------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> Our achievements speak for themselves. What we have to keep
>> track
>>>>>>>>>>>> of are our failures, discouragements and doubts. We tend to
>> forget
>>>>>>>>>>>> the past difficulties, the many false starts, and the painful
>>>>>>>>>>>> groping. We see our past achievements as the end result of a
>>>>>>>>>>>> clean forward thrust, and our present difficulties as
>>>>>>>>>>>> signs of decline and decay.
>>>>>>>>>>>> 
>>>>>>>>>>>> -- Eric Hoffer, Reflections on the Human Condition
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> -----
>>>>>>>>>>> Arnaud Héritier
>>>>>>>>>>> http://aheritier.net
>>>>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>>>>>> Twitter/Skype : aheritier
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Jeff MAURY
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> "Legacy code" often differs from its suggested alternative by
>>>> actually
>>>>>>>>>> working and scaling.
>>>>>>>>>> - Bjarne Stroustrup
>>>>>>>>>> 
>>>>>>>>>> http://www.jeffmaury.com
>>>>>>>>>> http://riadiscuss.jeffmaury.com
>>>>>>>>>> http://www.twitter.com/jeffmaury
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Baptiste <Batmat> MATHUS - http://batmat.net
>>>>>>>>>> Sauvez un arbre,
>>>>>>>>>> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Jason
>>>>>>>> 
>>>>>>>> ----------------------------------------------------------
>>>>>>>> Jason van Zyl
>>>>>>>> Founder & CTO, Sonatype
>>>>>>>> Founder,  Apache Maven
>>>>>>>> http://twitter.com/jvanzyl
>>>>>>>> ---------------------------------------------------------
>>>>>>>> 
>>>>>>>> To do two things at once is to do neither.
>>>>>>>> 
>>>>>>>> -- Publilius Syrus, Roman slave, first century B.C.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Jason
>>>>>> 
>>>>>> ----------------------------------------------------------
>>>>>> Jason van Zyl
>>>>>> Founder & CTO, Sonatype
>>>>>> Founder,  Apache Maven
>>>>>> http://twitter.com/jvanzyl
>>>>>> ---------------------------------------------------------
>>>>>> 
>>>>>> The modern conservative is engaged in one of man's oldest exercises in
>>>>>> moral philosophy; that is,
>>>>>> the search for a superior moral justification for selfishness.
>>>>>> 
>>>>>> -- John Kenneth Galbraith
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder & CTO, Sonatype
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>> 
>>>> What matters is not ideas, but the people who have them. Good people can
>>>> fix bad ideas, but good ideas can't save bad people.
>>>> 
>>>> -- Paul Graham
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> You are never dedicated to something you have complete confidence in.
>> No one is fanatically shouting that the sun is going to rise tomorrow.
>> They know it is going to rise tomorrow. When people are fanatically
>> dedicated to political or religious faiths or any other kind of
>> dogmas or goals, it's always because these dogmas or
>> goals are in doubt.
>> 
>>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>> 
>> 
>> 
>> 
>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society

Re: Pain with MNG-5181 (_maven.repositories)

[Jason van Zyl <ja...@tesla.io>]

You mind if I ping you off line? I have a couple things I'd like to test.

On Feb 3, 2013, at 6:21 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:

> Usually i comment all in this one
> Le 4 févr. 2013 00:20, "Jason van Zyl" <ja...@tesla.io> a écrit :
> 
>> Just so I'm clear do you switch between this settings.xml and no
>> settings.xml, or you just use this settings.xml all the time?
>> 
>> On Feb 3, 2013, at 5:15 PM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>> 
>>> here it is https://gist.github.com/c07256a99d3b2af322eb
>>> 
>>> @home i remove the settings.xml in general
>>> 
>>> *Romain Manni-Bucau*
>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>>> *Blog: **http://rmannibucau.wordpress.com/*<
>> http://rmannibucau.wordpress.com/>
>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>> *Github: https://github.com/rmannibucau*
>>> 
>>> 
>>> 
>>> 2013/2/3 Jason van Zyl <ja...@tesla.io>
>>> 
>>>> Would still be useful if you removed your passwords and sent me both
>>>> configurations, if this is happening to you with this configuration it's
>>>> probably happening to others. If I can give it a quick look I can
>> probably
>>>> tell you why the error is happening or determine if it is, in fact, a
>> bug.
>>>> 
>>>> On Feb 3, 2013, at 5:04 PM, Romain Manni-Bucau <rm...@gmail.com>
>>>> wrote:
>>>> 
>>>>> well nothing special in it (host/port/protocol proxies +
>>>> username/password
>>>>> servers).
>>>>> 
>>>>> however i build company projects using enterprise project having as
>>>>> dependencies tomee, could it generate it?
>>>>> 
>>>>> 
>>>>> *Romain Manni-Bucau*
>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>>>>> *Blog: **http://rmannibucau.wordpress.com/*<
>>>> http://rmannibucau.wordpress.com/>
>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>>>> *Github: https://github.com/rmannibucau*
>>>>> 
>>>>> 
>>>>> 
>>>>> 2013/2/3 Jason van Zyl <ja...@tesla.io>
>>>>> 
>>>>>> Can you send me the configurations?
>>>>>> 
>>>>>> If the artifacts are accessible and it fails then that's a bug. But I
>> am
>>>>>> willing to bet one configuration yields a different set of URLs to
>> which
>>>>>> particular artifacts are not accessible. If I can reproduce it then
>> this
>>>>>> will help contribute to an error message that's more useful.
>>>>>> 
>>>>>> On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau <rmannibucau@gmail.com
>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> I switch my settings and the only differences are:
>>>>>>> 
>>>>>>> 1) some server config (i guess that's not important)
>>>>>>> 2) (more important) proxies (host/port)
>>>>>>> 
>>>>>>> i don't use mirrorOf.
>>>>>>> 
>>>>>>> PS: the issue can happen with tomee trunk so repos are always
>> available
>>>>>>> since the internet is available.
>>>>>>> 
>>>>>>> *Romain Manni-Bucau*
>>>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>>>>>>> *Blog: **http://rmannibucau.wordpress.com/*<
>>>>>> http://rmannibucau.wordpress.com/>
>>>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>>>>>> *Github: https://github.com/rmannibucau*
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 2013/2/3 Jason van Zyl <ja...@tesla.io>
>>>>>>> 
>>>>>>>> If this is on one machine where you are not changing configurations
>> or
>>>>>>>> locations then something else is wrong as this does not happen for a
>>>>>>>> machine that stays in the same place using the same settings.xml. Do
>>>> you
>>>>>>>> use a mirrorOf in your settings.xml that points to a group
>> repository?
>>>>>> Can
>>>>>>>> you share your configuration? When you encounter this problem next,
>>>> move
>>>>>>>> your whole local repository out of the way (or use
>>>>>>>> -Dmaven.repo.local=/tmp/repo) and you find that the build will fail.
>>>>>>>> 
>>>>>>>> When this error occurs it means that the artifacts you're asking for
>>>> are
>>>>>>>> not available in any configured repository. You erase
>>>>>> _maven.repositories
>>>>>>>> file, and Maven does not verify that artifact's existence in the
>>>> remote
>>>>>>>> repository and let's you use the artifact you acquired locally by
>> some
>>>>>>>> other means.
>>>>>>>> 
>>>>>>>> This generally happens as a result of switching between
>> configurations
>>>>>>>> which changes the id/url of the repository you are using. You do a
>>>> build
>>>>>>>> against id=repo1(URL1) and get some artifacts and those are recorded
>>>> in
>>>>>> the
>>>>>>>> _maven.repositories files, and then you switch configurations and
>> use
>>>>>>>> id=repo2(URL2) and that repository doesn't have the artifacts you
>>>>>> acquired
>>>>>>>> from id=repo1(URL1).
>>>>>>>> 
>>>>>>>> The problem encountered for people flipping between using Central
>>>>>> directly
>>>>>>>> and using a mirrorOf setting with a repository manager is as
>> follows:
>>>>>>>> 
>>>>>>>> If you have no mirrorOf setting and you have POMs that contain
>>>>>> repository
>>>>>>>> entries Maven will follow the repositories in the POMs and acquire
>> any
>>>>>>>> dependencies from those repositories listed in the POMs. Now when
>> you
>>>>>> flip
>>>>>>>> to using a mirrorOf setting with a repository manager all those
>>>> requests
>>>>>>>> will be routed through that single URL. If you have not setup the
>>>>>> proxies
>>>>>>>> in your repository manager that correspond to the repositories in
>> the
>>>>>> POMs
>>>>>>>> the build will fail because those artifacts are not accessible to
>> the
>>>>>>>> repository manager.
>>>>>>>> 
>>>>>>>> On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau <
>> rmannibucau@gmail.com
>>>>> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hi guys,
>>>>>>>>> 
>>>>>>>>> Not sure it is linked or not (i read the thread lately) but at work
>>>> we
>>>>>>>> use
>>>>>>>>> a proxy and not at "home" and i often have to remove _maven.repo
>>>> files
>>>>>>>>> (both ways) to make my build work again...that's an everyday pain.
>>>>>>>>> Le 3 févr. 2013 21:41, "Jason van Zyl" <ja...@tesla.io> a écrit :
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net>
>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> +1.
>>>>>>>>>>> 
>>>>>>>>>>> Though the feature seems interesting, it should have had its own
>>>>>>>>>>> advertisement while being introduced.
>>>>>>>>>>> Even after re-reading
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
>>>>>>>>>>> I'm
>>>>>>>>>>> still unsure about where/when it would bite me.
>>>>>>>>>> 
>>>>>>>>>> Does this make sense to you?
>>>>>>>>>> 
>>>>>>>>>> ---
>>>>>>>>>> 
>>>>>>>>>> h1. Enhanced Remote Repository Support
>>>>>>>>>> 
>>>>>>>>>> The feature verifies that the remote repositories configured for
>> the
>>>>>>>>>> current build can be used to successfully resolve the artifact in
>>>>>>>> question.
>>>>>>>>>> If you retrieved an artifact in the past from Central and now
>>>> changed
>>>>>>>> your
>>>>>>>>>> build to only know about Nexus and it doesn't have any knowledge
>> of
>>>>>> that
>>>>>>>>>> artifact then the build is going to fail. Put differently, if you
>>>>>> purged
>>>>>>>>>> your local repo, your build won't work either. Neglecting offline
>>>>>> mode,
>>>>>>>> the
>>>>>>>>>> goal is to ensure that the resolution works if it could be
>> performed
>>>>>>>> using
>>>>>>>>>> a clean local repo with the current configuration. Giving
>> confidence
>>>>>>>> that
>>>>>>>>>> co-workers can reproduce the build and not depend on some artifact
>>>>>>>>>> magically being pulled down into your local repository in the past
>>>>>>>> which is
>>>>>>>>>> nowhere to be found in the configured remote repository.
>>>>>>>>>> 
>>>>>>>>>> ---
>>>>>>>>>> 
>>>>>>>>>> And would you want that off by default?
>>>>>>>>>> 
>>>>>>>>>>> As I know and like Maven quite well, if I was bitten by that, I
>>>> might
>>>>>>>> do
>>>>>>>>>>> some reseach and find jiras etc.
>>>>>>>>>>> 
>>>>>>>>>>> Others might just struggle to make it work and grow the maven
>>>> bashing
>>>>>>>>>> group
>>>>>>>>>>> as Jeff said.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 2013/2/1 Jeff MAURY <je...@jeffmaury.com>
>>>>>>>>>>> 
>>>>>>>>>>>> +1 on Arnaud's comments.
>>>>>>>>>>>> The main problem with this "feature" is that it is not
>> documented
>>>>>>>> thus I
>>>>>>>>>>>> can't explain the real reason why Maven download several times
>>>>>>>> released
>>>>>>>>>>>> artifacts and this causes members of the Maven bashing group to
>>>> grow
>>>>>>>>>>>> 
>>>>>>>>>>>> Jeff
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <
>>>>>> aheritier@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> My position was to propose the low cost possible solution to
>>>> have a
>>>>>>>>>> quick
>>>>>>>>>>>>> fix and not to wait for months.
>>>>>>>>>>>>> If it could be fixed/configurable in aether it may be the
>>>> solution
>>>>>> to
>>>>>>>>>>>>> follow but I'm not sure about the status of this 3rd party
>>>> project
>>>>>>>>>>>> (eclipse
>>>>>>>>>>>>> migration ...) on which we don't have the hand.
>>>>>>>>>>>>> Seriously I helped and lost MANY hours with this problem
>> because
>>>> it
>>>>>>>> is
>>>>>>>>>>>> hard
>>>>>>>>>>>>> to diagnose.
>>>>>>>>>>>>> I'm sure that many people abandoned to try to understand and
>> just
>>>>>>>>>> dropped
>>>>>>>>>>>>> their local repo or decided to downgraded to m2 (or to switch
>> to
>>>>>>>>>> another
>>>>>>>>>>>>> tool).
>>>>>>>>>>>>> I think we can have a lot of similar feedbacks.
>>>>>>>>>>>>> The worst thing is to have another thing that users don't
>>>>>> understand
>>>>>>>>>>>> (lake
>>>>>>>>>>>>> of documentation ? communication ?)
>>>>>>>>>>>>> The side effect is that changing a repository id (or mirror id)
>>>>>> makes
>>>>>>>>>>>> maven
>>>>>>>>>>>>> to re-download all the earth (while we are claiming from the
>>>>>>>> beginning
>>>>>>>>>>>> that
>>>>>>>>>>>>> Maven won't never download twice a release).
>>>>>>>>>>>>> And when the remote artifact just disappeared it is just a
>>>>>> nightmare
>>>>>>>>>> due
>>>>>>>>>>>> to
>>>>>>>>>>>>> the lake of correct logs and this case is easy to have.
>>>>>>>>>>>>> For example in my company I have a profile to let people DL
>>>>>> artifacts
>>>>>>>>>>>> from
>>>>>>>>>>>>> staging repositories (thus these are releases). It happened
>> that
>>>>>> they
>>>>>>>>>>>>> activated it once to test a build and then they rebuild the
>>>> project
>>>>>>>>>>>> without
>>>>>>>>>>>>> the profile (thinking the artifact is in the local repo) and it
>>>>>> fails
>>>>>>>>>> ...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Sincerely I think I had my worst headaches with maven due to
>> this
>>>>>> bug
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io>
>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <
>>>> aheritier@gmail.com
>>>>>>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi Olivier,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thx a lot for the fix. It will help a lot the community.
>>>>>>>>>>>>>>> But from my point of view it's perhaps not yet enough.
>>>>>>>>>>>>>>> We should :
>>>>>>>>>>>>>>> 1/ change the default behavior to deactivate this control
>> which
>>>>>> is
>>>>>>>>>>>>>>> difficult to understand
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I disagree. We may want to change it slightly but it's only a
>>>>>>>> problem
>>>>>>>>>>>> for
>>>>>>>>>>>>>> people who flip between Maven a repository manager and without
>>>> but
>>>>>>>>>> it's
>>>>>>>>>>>>> to
>>>>>>>>>>>>>> ensure the identity of a component. I haven't seen a huge
>> number
>>>>>> of
>>>>>>>>>>>>>> complaints. I do not want to turn this off. Improve it, sure,
>>>> but
>>>>>>>>>>>> turning
>>>>>>>>>>>>>> it off by default I believe is not the right thing to do.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 2/ change the error message when this control is activated to
>>>>>>>>>>>> clearly
>>>>>>>>>>>>>>> explain that the problem comes from the unavailability of the
>>>>>>>>>>>> artifact
>>>>>>>>>>>>> on
>>>>>>>>>>>>>>> its original remote repo.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> For me 1/ is mandatory and 2/ a nice to have
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> WDYT ?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <
>>>> olamy@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I have pushed a fix for that.
>>>>>>>>>>>>>>>> Now you can desactivate the enhanced local repository using:
>>>>>>>>>>>>>>>> * new cli option: -slrm,--simple-local-repository-manager
>>>>>>>>>>>>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> will be available for testing here
>>>>>>>>>>>>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
>>>>>>>>>>>>>>>>> Hi Arnaud,
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> +1 to consider the current behavior as a bug.
>>>>>>>>>>>>>>>>>> We should be able to deactivate it easily (and perhaps to
>>>> have
>>>>>>>> it
>>>>>>>>>>>>> off
>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>> default to activate it only on CI servers)
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> and we should take care to have
>>>>>>>>>>>>>>>>>> a real error message explaining the issue and not a
>>>> classical
>>>>>>>>>>>>>> dependency
>>>>>>>>>>>>>>>>>> not found while the artifact is in the local repo.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> This is exactly filed here:
>>>>>>>>>>>>>>>>> http://jira.codehaus.org/browse/MNG-5185
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Arnaud
>>>>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>>>>> Jörg
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> If know-how becomes know-where, then knowledge gets
>> nowhere.
>>>>>>>>>>>>>>>>> [Jörg Hohwiller]
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Olivier Lamy
>>>>>>>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>> Arnaud Héritier
>>>>>>>>>>>>>>> http://aheritier.net
>>>>>>>>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>>>>>>>>>> Twitter/Skype : aheritier
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Jason
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ----------------------------------------------------------
>>>>>>>>>>>>>> Jason van Zyl
>>>>>>>>>>>>>> Founder & CTO, Sonatype
>>>>>>>>>>>>>> Founder,  Apache Maven
>>>>>>>>>>>>>> http://twitter.com/jvanzyl
>>>>>>>>>>>>>> ---------------------------------------------------------
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Our achievements speak for themselves. What we have to keep
>>>> track
>>>>>>>>>>>>>> of are our failures, discouragements and doubts. We tend to
>>>> forget
>>>>>>>>>>>>>> the past difficulties, the many false starts, and the painful
>>>>>>>>>>>>>> groping. We see our past achievements as the end result of a
>>>>>>>>>>>>>> clean forward thrust, and our present difficulties as
>>>>>>>>>>>>>> signs of decline and decay.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -- Eric Hoffer, Reflections on the Human Condition
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> -----
>>>>>>>>>>>>> Arnaud Héritier
>>>>>>>>>>>>> http://aheritier.net
>>>>>>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>>>>>>>> Twitter/Skype : aheritier
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Jeff MAURY
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> "Legacy code" often differs from its suggested alternative by
>>>>>> actually
>>>>>>>>>>>> working and scaling.
>>>>>>>>>>>> - Bjarne Stroustrup
>>>>>>>>>>>> 
>>>>>>>>>>>> http://www.jeffmaury.com
>>>>>>>>>>>> http://riadiscuss.jeffmaury.com
>>>>>>>>>>>> http://www.twitter.com/jeffmaury
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Baptiste <Batmat> MATHUS - http://batmat.net
>>>>>>>>>>>> Sauvez un arbre,
>>>>>>>>>>>> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> 
>>>>>>>>>> Jason
>>>>>>>>>> 
>>>>>>>>>> ----------------------------------------------------------
>>>>>>>>>> Jason van Zyl
>>>>>>>>>> Founder & CTO, Sonatype
>>>>>>>>>> Founder,  Apache Maven
>>>>>>>>>> http://twitter.com/jvanzyl
>>>>>>>>>> ---------------------------------------------------------
>>>>>>>>>> 
>>>>>>>>>> To do two things at once is to do neither.
>>>>>>>>>> 
>>>>>>>>>> -- Publilius Syrus, Roman slave, first century B.C.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Jason
>>>>>>>> 
>>>>>>>> ----------------------------------------------------------
>>>>>>>> Jason van Zyl
>>>>>>>> Founder & CTO, Sonatype
>>>>>>>> Founder,  Apache Maven
>>>>>>>> http://twitter.com/jvanzyl
>>>>>>>> ---------------------------------------------------------
>>>>>>>> 
>>>>>>>> The modern conservative is engaged in one of man's oldest exercises
>> in
>>>>>>>> moral philosophy; that is,
>>>>>>>> the search for a superior moral justification for selfishness.
>>>>>>>> 
>>>>>>>> -- John Kenneth Galbraith
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Jason
>>>>>> 
>>>>>> ----------------------------------------------------------
>>>>>> Jason van Zyl
>>>>>> Founder & CTO, Sonatype
>>>>>> Founder,  Apache Maven
>>>>>> http://twitter.com/jvanzyl
>>>>>> ---------------------------------------------------------
>>>>>> 
>>>>>> What matters is not ideas, but the people who have them. Good people
>> can
>>>>>> fix bad ideas, but good ideas can't save bad people.
>>>>>> 
>>>>>> -- Paul Graham
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder & CTO, Sonatype
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>> 
>>>> You are never dedicated to something you have complete confidence in.
>>>> No one is fanatically shouting that the sun is going to rise tomorrow.
>>>> They know it is going to rise tomorrow. When people are fanatically
>>>> dedicated to political or religious faiths or any other kind of
>>>> dogmas or goals, it's always because these dogmas or
>>>> goals are in doubt.
>>>> 
>>>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> A party which is not afraid of letting culture,
>> business, and welfare go to ruin completely can
>> be omnipotent for a while.
>> 
>>  -- Jakob Burckhardt
>> 
>> 
>> 
>> 
>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.

 -- Eric Hoffer, Reflections on the Human Condition

Re: Pain with MNG-5181 (_maven.repositories)

[Romain Manni-Bucau <rm...@gmail.com>]

Usually i comment all in this one
Le 4 févr. 2013 00:20, "Jason van Zyl" <ja...@tesla.io> a écrit :

> Just so I'm clear do you switch between this settings.xml and no
> settings.xml, or you just use this settings.xml all the time?
>
> On Feb 3, 2013, at 5:15 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > here it is https://gist.github.com/c07256a99d3b2af322eb
> >
> > @home i remove the settings.xml in general
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/2/3 Jason van Zyl <ja...@tesla.io>
> >
> >> Would still be useful if you removed your passwords and sent me both
> >> configurations, if this is happening to you with this configuration it's
> >> probably happening to others. If I can give it a quick look I can
> probably
> >> tell you why the error is happening or determine if it is, in fact, a
> bug.
> >>
> >> On Feb 3, 2013, at 5:04 PM, Romain Manni-Bucau <rm...@gmail.com>
> >> wrote:
> >>
> >>> well nothing special in it (host/port/protocol proxies +
> >> username/password
> >>> servers).
> >>>
> >>> however i build company projects using enterprise project having as
> >>> dependencies tomee, could it generate it?
> >>>
> >>>
> >>> *Romain Manni-Bucau*
> >>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >>> *Blog: **http://rmannibucau.wordpress.com/*<
> >> http://rmannibucau.wordpress.com/>
> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >>> *Github: https://github.com/rmannibucau*
> >>>
> >>>
> >>>
> >>> 2013/2/3 Jason van Zyl <ja...@tesla.io>
> >>>
> >>>> Can you send me the configurations?
> >>>>
> >>>> If the artifacts are accessible and it fails then that's a bug. But I
> am
> >>>> willing to bet one configuration yields a different set of URLs to
> which
> >>>> particular artifacts are not accessible. If I can reproduce it then
> this
> >>>> will help contribute to an error message that's more useful.
> >>>>
> >>>> On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> >>>> wrote:
> >>>>
> >>>>> I switch my settings and the only differences are:
> >>>>>
> >>>>> 1) some server config (i guess that's not important)
> >>>>> 2) (more important) proxies (host/port)
> >>>>>
> >>>>> i don't use mirrorOf.
> >>>>>
> >>>>> PS: the issue can happen with tomee trunk so repos are always
> available
> >>>>> since the internet is available.
> >>>>>
> >>>>> *Romain Manni-Bucau*
> >>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >>>>> *Blog: **http://rmannibucau.wordpress.com/*<
> >>>> http://rmannibucau.wordpress.com/>
> >>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >>>>> *Github: https://github.com/rmannibucau*
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2013/2/3 Jason van Zyl <ja...@tesla.io>
> >>>>>
> >>>>>> If this is on one machine where you are not changing configurations
> or
> >>>>>> locations then something else is wrong as this does not happen for a
> >>>>>> machine that stays in the same place using the same settings.xml. Do
> >> you
> >>>>>> use a mirrorOf in your settings.xml that points to a group
> repository?
> >>>> Can
> >>>>>> you share your configuration? When you encounter this problem next,
> >> move
> >>>>>> your whole local repository out of the way (or use
> >>>>>> -Dmaven.repo.local=/tmp/repo) and you find that the build will fail.
> >>>>>>
> >>>>>> When this error occurs it means that the artifacts you're asking for
> >> are
> >>>>>> not available in any configured repository. You erase
> >>>> _maven.repositories
> >>>>>> file, and Maven does not verify that artifact's existence in the
> >> remote
> >>>>>> repository and let's you use the artifact you acquired locally by
> some
> >>>>>> other means.
> >>>>>>
> >>>>>> This generally happens as a result of switching between
> configurations
> >>>>>> which changes the id/url of the repository you are using. You do a
> >> build
> >>>>>> against id=repo1(URL1) and get some artifacts and those are recorded
> >> in
> >>>> the
> >>>>>> _maven.repositories files, and then you switch configurations and
> use
> >>>>>> id=repo2(URL2) and that repository doesn't have the artifacts you
> >>>> acquired
> >>>>>> from id=repo1(URL1).
> >>>>>>
> >>>>>> The problem encountered for people flipping between using Central
> >>>> directly
> >>>>>> and using a mirrorOf setting with a repository manager is as
> follows:
> >>>>>>
> >>>>>> If you have no mirrorOf setting and you have POMs that contain
> >>>> repository
> >>>>>> entries Maven will follow the repositories in the POMs and acquire
> any
> >>>>>> dependencies from those repositories listed in the POMs. Now when
> you
> >>>> flip
> >>>>>> to using a mirrorOf setting with a repository manager all those
> >> requests
> >>>>>> will be routed through that single URL. If you have not setup the
> >>>> proxies
> >>>>>> in your repository manager that correspond to the repositories in
> the
> >>>> POMs
> >>>>>> the build will fail because those artifacts are not accessible to
> the
> >>>>>> repository manager.
> >>>>>>
> >>>>>> On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> >>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi guys,
> >>>>>>>
> >>>>>>> Not sure it is linked or not (i read the thread lately) but at work
> >> we
> >>>>>> use
> >>>>>>> a proxy and not at "home" and i often have to remove _maven.repo
> >> files
> >>>>>>> (both ways) to make my build work again...that's an everyday pain.
> >>>>>>> Le 3 févr. 2013 21:41, "Jason van Zyl" <ja...@tesla.io> a écrit :
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net>
> wrote:
> >>>>>>>>
> >>>>>>>>> +1.
> >>>>>>>>>
> >>>>>>>>> Though the feature seems interesting, it should have had its own
> >>>>>>>>> advertisement while being introduced.
> >>>>>>>>> Even after re-reading
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
> >>>>>>>>> I'm
> >>>>>>>>> still unsure about where/when it would bite me.
> >>>>>>>>
> >>>>>>>> Does this make sense to you?
> >>>>>>>>
> >>>>>>>> ---
> >>>>>>>>
> >>>>>>>> h1. Enhanced Remote Repository Support
> >>>>>>>>
> >>>>>>>> The feature verifies that the remote repositories configured for
> the
> >>>>>>>> current build can be used to successfully resolve the artifact in
> >>>>>> question.
> >>>>>>>> If you retrieved an artifact in the past from Central and now
> >> changed
> >>>>>> your
> >>>>>>>> build to only know about Nexus and it doesn't have any knowledge
> of
> >>>> that
> >>>>>>>> artifact then the build is going to fail. Put differently, if you
> >>>> purged
> >>>>>>>> your local repo, your build won't work either. Neglecting offline
> >>>> mode,
> >>>>>> the
> >>>>>>>> goal is to ensure that the resolution works if it could be
> performed
> >>>>>> using
> >>>>>>>> a clean local repo with the current configuration. Giving
> confidence
> >>>>>> that
> >>>>>>>> co-workers can reproduce the build and not depend on some artifact
> >>>>>>>> magically being pulled down into your local repository in the past
> >>>>>> which is
> >>>>>>>> nowhere to be found in the configured remote repository.
> >>>>>>>>
> >>>>>>>> ---
> >>>>>>>>
> >>>>>>>> And would you want that off by default?
> >>>>>>>>
> >>>>>>>>> As I know and like Maven quite well, if I was bitten by that, I
> >> might
> >>>>>> do
> >>>>>>>>> some reseach and find jiras etc.
> >>>>>>>>>
> >>>>>>>>> Others might just struggle to make it work and grow the maven
> >> bashing
> >>>>>>>> group
> >>>>>>>>> as Jeff said.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 2013/2/1 Jeff MAURY <je...@jeffmaury.com>
> >>>>>>>>>
> >>>>>>>>>> +1 on Arnaud's comments.
> >>>>>>>>>> The main problem with this "feature" is that it is not
> documented
> >>>>>> thus I
> >>>>>>>>>> can't explain the real reason why Maven download several times
> >>>>>> released
> >>>>>>>>>> artifacts and this causes members of the Maven bashing group to
> >> grow
> >>>>>>>>>>
> >>>>>>>>>> Jeff
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <
> >>>> aheritier@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> My position was to propose the low cost possible solution to
> >> have a
> >>>>>>>> quick
> >>>>>>>>>>> fix and not to wait for months.
> >>>>>>>>>>> If it could be fixed/configurable in aether it may be the
> >> solution
> >>>> to
> >>>>>>>>>>> follow but I'm not sure about the status of this 3rd party
> >> project
> >>>>>>>>>> (eclipse
> >>>>>>>>>>> migration ...) on which we don't have the hand.
> >>>>>>>>>>> Seriously I helped and lost MANY hours with this problem
> because
> >> it
> >>>>>> is
> >>>>>>>>>> hard
> >>>>>>>>>>> to diagnose.
> >>>>>>>>>>> I'm sure that many people abandoned to try to understand and
> just
> >>>>>>>> dropped
> >>>>>>>>>>> their local repo or decided to downgraded to m2 (or to switch
> to
> >>>>>>>> another
> >>>>>>>>>>> tool).
> >>>>>>>>>>> I think we can have a lot of similar feedbacks.
> >>>>>>>>>>> The worst thing is to have another thing that users don't
> >>>> understand
> >>>>>>>>>> (lake
> >>>>>>>>>>> of documentation ? communication ?)
> >>>>>>>>>>> The side effect is that changing a repository id (or mirror id)
> >>>> makes
> >>>>>>>>>> maven
> >>>>>>>>>>> to re-download all the earth (while we are claiming from the
> >>>>>> beginning
> >>>>>>>>>> that
> >>>>>>>>>>> Maven won't never download twice a release).
> >>>>>>>>>>> And when the remote artifact just disappeared it is just a
> >>>> nightmare
> >>>>>>>> due
> >>>>>>>>>> to
> >>>>>>>>>>> the lake of correct logs and this case is easy to have.
> >>>>>>>>>>> For example in my company I have a profile to let people DL
> >>>> artifacts
> >>>>>>>>>> from
> >>>>>>>>>>> staging repositories (thus these are releases). It happened
> that
> >>>> they
> >>>>>>>>>>> activated it once to test a build and then they rebuild the
> >> project
> >>>>>>>>>> without
> >>>>>>>>>>> the profile (thinking the artifact is in the local repo) and it
> >>>> fails
> >>>>>>>> ...
> >>>>>>>>>>>
> >>>>>>>>>>> Sincerely I think I had my worst headaches with maven due to
> this
> >>>> bug
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io>
> >>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <
> >> aheritier@gmail.com
> >>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hi Olivier,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thx a lot for the fix. It will help a lot the community.
> >>>>>>>>>>>>> But from my point of view it's perhaps not yet enough.
> >>>>>>>>>>>>> We should :
> >>>>>>>>>>>>> 1/ change the default behavior to deactivate this control
> which
> >>>> is
> >>>>>>>>>>>>> difficult to understand
> >>>>>>>>>>>>
> >>>>>>>>>>>> I disagree. We may want to change it slightly but it's only a
> >>>>>> problem
> >>>>>>>>>> for
> >>>>>>>>>>>> people who flip between Maven a repository manager and without
> >> but
> >>>>>>>> it's
> >>>>>>>>>>> to
> >>>>>>>>>>>> ensure the identity of a component. I haven't seen a huge
> number
> >>>> of
> >>>>>>>>>>>> complaints. I do not want to turn this off. Improve it, sure,
> >> but
> >>>>>>>>>> turning
> >>>>>>>>>>>> it off by default I believe is not the right thing to do.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 2/ change the error message when this control is activated to
> >>>>>>>>>> clearly
> >>>>>>>>>>>>> explain that the problem comes from the unavailability of the
> >>>>>>>>>> artifact
> >>>>>>>>>>> on
> >>>>>>>>>>>>> its original remote repo.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For me 1/ is mandatory and 2/ a nice to have
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> WDYT ?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <
> >> olamy@apache.org>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> I have pushed a fix for that.
> >>>>>>>>>>>>>> Now you can desactivate the enhanced local repository using:
> >>>>>>>>>>>>>> * new cli option: -slrm,--simple-local-repository-manager
> >>>>>>>>>>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> will be available for testing here
> >>>>>>>>>>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
> >>>>>>>>>>>>>>> Hi Arnaud,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> +1 to consider the current behavior as a bug.
> >>>>>>>>>>>>>>>> We should be able to deactivate it easily (and perhaps to
> >> have
> >>>>>> it
> >>>>>>>>>>> off
> >>>>>>>>>>>> by
> >>>>>>>>>>>>>>>> default to activate it only on CI servers)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> :)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> and we should take care to have
> >>>>>>>>>>>>>>>> a real error message explaining the issue and not a
> >> classical
> >>>>>>>>>>>> dependency
> >>>>>>>>>>>>>>>> not found while the artifact is in the local repo.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This is exactly filed here:
> >>>>>>>>>>>>>>> http://jira.codehaus.org/browse/MNG-5185
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Arnaud
> >>>>>>>>>>>>>>> Cheers
> >>>>>>>>>>>>>>> Jörg
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> If know-how becomes know-where, then knowledge gets
> nowhere.
> >>>>>>>>>>>>>>> [Jörg Hohwiller]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Olivier Lamy
> >>>>>>>>>>>>>> Talend: http://coders.talend.com
> >>>>>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> -----
> >>>>>>>>>>>>> Arnaud Héritier
> >>>>>>>>>>>>> http://aheritier.net
> >>>>>>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
> >>>>>>>>>>>>> Twitter/Skype : aheritier
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Jason
> >>>>>>>>>>>>
> >>>>>>>>>>>> ----------------------------------------------------------
> >>>>>>>>>>>> Jason van Zyl
> >>>>>>>>>>>> Founder & CTO, Sonatype
> >>>>>>>>>>>> Founder,  Apache Maven
> >>>>>>>>>>>> http://twitter.com/jvanzyl
> >>>>>>>>>>>> ---------------------------------------------------------
> >>>>>>>>>>>>
> >>>>>>>>>>>> Our achievements speak for themselves. What we have to keep
> >> track
> >>>>>>>>>>>> of are our failures, discouragements and doubts. We tend to
> >> forget
> >>>>>>>>>>>> the past difficulties, the many false starts, and the painful
> >>>>>>>>>>>> groping. We see our past achievements as the end result of a
> >>>>>>>>>>>> clean forward thrust, and our present difficulties as
> >>>>>>>>>>>> signs of decline and decay.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -- Eric Hoffer, Reflections on the Human Condition
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> -----
> >>>>>>>>>>> Arnaud Héritier
> >>>>>>>>>>> http://aheritier.net
> >>>>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
> >>>>>>>>>>> Twitter/Skype : aheritier
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Jeff MAURY
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> "Legacy code" often differs from its suggested alternative by
> >>>> actually
> >>>>>>>>>> working and scaling.
> >>>>>>>>>> - Bjarne Stroustrup
> >>>>>>>>>>
> >>>>>>>>>> http://www.jeffmaury.com
> >>>>>>>>>> http://riadiscuss.jeffmaury.com
> >>>>>>>>>> http://www.twitter.com/jeffmaury
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Baptiste <Batmat> MATHUS - http://batmat.net
> >>>>>>>>>> Sauvez un arbre,
> >>>>>>>>>> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Jason
> >>>>>>>>
> >>>>>>>> ----------------------------------------------------------
> >>>>>>>> Jason van Zyl
> >>>>>>>> Founder & CTO, Sonatype
> >>>>>>>> Founder,  Apache Maven
> >>>>>>>> http://twitter.com/jvanzyl
> >>>>>>>> ---------------------------------------------------------
> >>>>>>>>
> >>>>>>>> To do two things at once is to do neither.
> >>>>>>>>
> >>>>>>>> -- Publilius Syrus, Roman slave, first century B.C.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Jason
> >>>>>>
> >>>>>> ----------------------------------------------------------
> >>>>>> Jason van Zyl
> >>>>>> Founder & CTO, Sonatype
> >>>>>> Founder,  Apache Maven
> >>>>>> http://twitter.com/jvanzyl
> >>>>>> ---------------------------------------------------------
> >>>>>>
> >>>>>> The modern conservative is engaged in one of man's oldest exercises
> in
> >>>>>> moral philosophy; that is,
> >>>>>> the search for a superior moral justification for selfishness.
> >>>>>>
> >>>>>> -- John Kenneth Galbraith
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jason
> >>>>
> >>>> ----------------------------------------------------------
> >>>> Jason van Zyl
> >>>> Founder & CTO, Sonatype
> >>>> Founder,  Apache Maven
> >>>> http://twitter.com/jvanzyl
> >>>> ---------------------------------------------------------
> >>>>
> >>>> What matters is not ideas, but the people who have them. Good people
> can
> >>>> fix bad ideas, but good ideas can't save bad people.
> >>>>
> >>>> -- Paul Graham
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder & CTO, Sonatype
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >>
> >> You are never dedicated to something you have complete confidence in.
> >> No one is fanatically shouting that the sun is going to rise tomorrow.
> >> They know it is going to rise tomorrow. When people are fanatically
> >> dedicated to political or religious faiths or any other kind of
> >> dogmas or goals, it's always because these dogmas or
> >> goals are in doubt.
> >>
> >>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
> >>
> >>
> >>
> >>
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
>
>   -- Jakob Burckhardt
>
>
>
>
>
>

Re: Pain with MNG-5181 (_maven.repositories)

[Jason van Zyl <ja...@tesla.io>]

Just so I'm clear do you switch between this settings.xml and no settings.xml, or you just use this settings.xml all the time?

On Feb 3, 2013, at 5:15 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:

> here it is https://gist.github.com/c07256a99d3b2af322eb
> 
> @home i remove the settings.xml in general
> 
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
> 
> 
> 
> 2013/2/3 Jason van Zyl <ja...@tesla.io>
> 
>> Would still be useful if you removed your passwords and sent me both
>> configurations, if this is happening to you with this configuration it's
>> probably happening to others. If I can give it a quick look I can probably
>> tell you why the error is happening or determine if it is, in fact, a bug.
>> 
>> On Feb 3, 2013, at 5:04 PM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>> 
>>> well nothing special in it (host/port/protocol proxies +
>> username/password
>>> servers).
>>> 
>>> however i build company projects using enterprise project having as
>>> dependencies tomee, could it generate it?
>>> 
>>> 
>>> *Romain Manni-Bucau*
>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>>> *Blog: **http://rmannibucau.wordpress.com/*<
>> http://rmannibucau.wordpress.com/>
>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>> *Github: https://github.com/rmannibucau*
>>> 
>>> 
>>> 
>>> 2013/2/3 Jason van Zyl <ja...@tesla.io>
>>> 
>>>> Can you send me the configurations?
>>>> 
>>>> If the artifacts are accessible and it fails then that's a bug. But I am
>>>> willing to bet one configuration yields a different set of URLs to which
>>>> particular artifacts are not accessible. If I can reproduce it then this
>>>> will help contribute to an error message that's more useful.
>>>> 
>>>> On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau <rm...@gmail.com>
>>>> wrote:
>>>> 
>>>>> I switch my settings and the only differences are:
>>>>> 
>>>>> 1) some server config (i guess that's not important)
>>>>> 2) (more important) proxies (host/port)
>>>>> 
>>>>> i don't use mirrorOf.
>>>>> 
>>>>> PS: the issue can happen with tomee trunk so repos are always available
>>>>> since the internet is available.
>>>>> 
>>>>> *Romain Manni-Bucau*
>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>>>>> *Blog: **http://rmannibucau.wordpress.com/*<
>>>> http://rmannibucau.wordpress.com/>
>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>>>> *Github: https://github.com/rmannibucau*
>>>>> 
>>>>> 
>>>>> 
>>>>> 2013/2/3 Jason van Zyl <ja...@tesla.io>
>>>>> 
>>>>>> If this is on one machine where you are not changing configurations or
>>>>>> locations then something else is wrong as this does not happen for a
>>>>>> machine that stays in the same place using the same settings.xml. Do
>> you
>>>>>> use a mirrorOf in your settings.xml that points to a group repository?
>>>> Can
>>>>>> you share your configuration? When you encounter this problem next,
>> move
>>>>>> your whole local repository out of the way (or use
>>>>>> -Dmaven.repo.local=/tmp/repo) and you find that the build will fail.
>>>>>> 
>>>>>> When this error occurs it means that the artifacts you're asking for
>> are
>>>>>> not available in any configured repository. You erase
>>>> _maven.repositories
>>>>>> file, and Maven does not verify that artifact's existence in the
>> remote
>>>>>> repository and let's you use the artifact you acquired locally by some
>>>>>> other means.
>>>>>> 
>>>>>> This generally happens as a result of switching between configurations
>>>>>> which changes the id/url of the repository you are using. You do a
>> build
>>>>>> against id=repo1(URL1) and get some artifacts and those are recorded
>> in
>>>> the
>>>>>> _maven.repositories files, and then you switch configurations and use
>>>>>> id=repo2(URL2) and that repository doesn't have the artifacts you
>>>> acquired
>>>>>> from id=repo1(URL1).
>>>>>> 
>>>>>> The problem encountered for people flipping between using Central
>>>> directly
>>>>>> and using a mirrorOf setting with a repository manager is as follows:
>>>>>> 
>>>>>> If you have no mirrorOf setting and you have POMs that contain
>>>> repository
>>>>>> entries Maven will follow the repositories in the POMs and acquire any
>>>>>> dependencies from those repositories listed in the POMs. Now when you
>>>> flip
>>>>>> to using a mirrorOf setting with a repository manager all those
>> requests
>>>>>> will be routed through that single URL. If you have not setup the
>>>> proxies
>>>>>> in your repository manager that correspond to the repositories in the
>>>> POMs
>>>>>> the build will fail because those artifacts are not accessible to the
>>>>>> repository manager.
>>>>>> 
>>>>>> On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau <rmannibucau@gmail.com
>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi guys,
>>>>>>> 
>>>>>>> Not sure it is linked or not (i read the thread lately) but at work
>> we
>>>>>> use
>>>>>>> a proxy and not at "home" and i often have to remove _maven.repo
>> files
>>>>>>> (both ways) to make my build work again...that's an everyday pain.
>>>>>>> Le 3 févr. 2013 21:41, "Jason van Zyl" <ja...@tesla.io> a écrit :
>>>>>>> 
>>>>>>>> 
>>>>>>>> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
>>>>>>>> 
>>>>>>>>> +1.
>>>>>>>>> 
>>>>>>>>> Though the feature seems interesting, it should have had its own
>>>>>>>>> advertisement while being introduced.
>>>>>>>>> Even after re-reading
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
>>>>>>>>> I'm
>>>>>>>>> still unsure about where/when it would bite me.
>>>>>>>> 
>>>>>>>> Does this make sense to you?
>>>>>>>> 
>>>>>>>> ---
>>>>>>>> 
>>>>>>>> h1. Enhanced Remote Repository Support
>>>>>>>> 
>>>>>>>> The feature verifies that the remote repositories configured for the
>>>>>>>> current build can be used to successfully resolve the artifact in
>>>>>> question.
>>>>>>>> If you retrieved an artifact in the past from Central and now
>> changed
>>>>>> your
>>>>>>>> build to only know about Nexus and it doesn't have any knowledge of
>>>> that
>>>>>>>> artifact then the build is going to fail. Put differently, if you
>>>> purged
>>>>>>>> your local repo, your build won't work either. Neglecting offline
>>>> mode,
>>>>>> the
>>>>>>>> goal is to ensure that the resolution works if it could be performed
>>>>>> using
>>>>>>>> a clean local repo with the current configuration. Giving confidence
>>>>>> that
>>>>>>>> co-workers can reproduce the build and not depend on some artifact
>>>>>>>> magically being pulled down into your local repository in the past
>>>>>> which is
>>>>>>>> nowhere to be found in the configured remote repository.
>>>>>>>> 
>>>>>>>> ---
>>>>>>>> 
>>>>>>>> And would you want that off by default?
>>>>>>>> 
>>>>>>>>> As I know and like Maven quite well, if I was bitten by that, I
>> might
>>>>>> do
>>>>>>>>> some reseach and find jiras etc.
>>>>>>>>> 
>>>>>>>>> Others might just struggle to make it work and grow the maven
>> bashing
>>>>>>>> group
>>>>>>>>> as Jeff said.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2013/2/1 Jeff MAURY <je...@jeffmaury.com>
>>>>>>>>> 
>>>>>>>>>> +1 on Arnaud's comments.
>>>>>>>>>> The main problem with this "feature" is that it is not documented
>>>>>> thus I
>>>>>>>>>> can't explain the real reason why Maven download several times
>>>>>> released
>>>>>>>>>> artifacts and this causes members of the Maven bashing group to
>> grow
>>>>>>>>>> 
>>>>>>>>>> Jeff
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <
>>>> aheritier@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> My position was to propose the low cost possible solution to
>> have a
>>>>>>>> quick
>>>>>>>>>>> fix and not to wait for months.
>>>>>>>>>>> If it could be fixed/configurable in aether it may be the
>> solution
>>>> to
>>>>>>>>>>> follow but I'm not sure about the status of this 3rd party
>> project
>>>>>>>>>> (eclipse
>>>>>>>>>>> migration ...) on which we don't have the hand.
>>>>>>>>>>> Seriously I helped and lost MANY hours with this problem because
>> it
>>>>>> is
>>>>>>>>>> hard
>>>>>>>>>>> to diagnose.
>>>>>>>>>>> I'm sure that many people abandoned to try to understand and just
>>>>>>>> dropped
>>>>>>>>>>> their local repo or decided to downgraded to m2 (or to switch to
>>>>>>>> another
>>>>>>>>>>> tool).
>>>>>>>>>>> I think we can have a lot of similar feedbacks.
>>>>>>>>>>> The worst thing is to have another thing that users don't
>>>> understand
>>>>>>>>>> (lake
>>>>>>>>>>> of documentation ? communication ?)
>>>>>>>>>>> The side effect is that changing a repository id (or mirror id)
>>>> makes
>>>>>>>>>> maven
>>>>>>>>>>> to re-download all the earth (while we are claiming from the
>>>>>> beginning
>>>>>>>>>> that
>>>>>>>>>>> Maven won't never download twice a release).
>>>>>>>>>>> And when the remote artifact just disappeared it is just a
>>>> nightmare
>>>>>>>> due
>>>>>>>>>> to
>>>>>>>>>>> the lake of correct logs and this case is easy to have.
>>>>>>>>>>> For example in my company I have a profile to let people DL
>>>> artifacts
>>>>>>>>>> from
>>>>>>>>>>> staging repositories (thus these are releases). It happened that
>>>> they
>>>>>>>>>>> activated it once to test a build and then they rebuild the
>> project
>>>>>>>>>> without
>>>>>>>>>>> the profile (thinking the artifact is in the local repo) and it
>>>> fails
>>>>>>>> ...
>>>>>>>>>>> 
>>>>>>>>>>> Sincerely I think I had my worst headaches with maven due to this
>>>> bug
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io>
>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <
>> aheritier@gmail.com
>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Olivier,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thx a lot for the fix. It will help a lot the community.
>>>>>>>>>>>>> But from my point of view it's perhaps not yet enough.
>>>>>>>>>>>>> We should :
>>>>>>>>>>>>> 1/ change the default behavior to deactivate this control which
>>>> is
>>>>>>>>>>>>> difficult to understand
>>>>>>>>>>>> 
>>>>>>>>>>>> I disagree. We may want to change it slightly but it's only a
>>>>>> problem
>>>>>>>>>> for
>>>>>>>>>>>> people who flip between Maven a repository manager and without
>> but
>>>>>>>> it's
>>>>>>>>>>> to
>>>>>>>>>>>> ensure the identity of a component. I haven't seen a huge number
>>>> of
>>>>>>>>>>>> complaints. I do not want to turn this off. Improve it, sure,
>> but
>>>>>>>>>> turning
>>>>>>>>>>>> it off by default I believe is not the right thing to do.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 2/ change the error message when this control is activated to
>>>>>>>>>> clearly
>>>>>>>>>>>>> explain that the problem comes from the unavailability of the
>>>>>>>>>> artifact
>>>>>>>>>>> on
>>>>>>>>>>>>> its original remote repo.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> For me 1/ is mandatory and 2/ a nice to have
>>>>>>>>>>>>> 
>>>>>>>>>>>>> WDYT ?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <
>> olamy@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I have pushed a fix for that.
>>>>>>>>>>>>>> Now you can desactivate the enhanced local repository using:
>>>>>>>>>>>>>> * new cli option: -slrm,--simple-local-repository-manager
>>>>>>>>>>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> will be available for testing here
>>>>>>>>>>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
>>>>>>>>>>>>>>> Hi Arnaud,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> +1 to consider the current behavior as a bug.
>>>>>>>>>>>>>>>> We should be able to deactivate it easily (and perhaps to
>> have
>>>>>> it
>>>>>>>>>>> off
>>>>>>>>>>>> by
>>>>>>>>>>>>>>>> default to activate it only on CI servers)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> and we should take care to have
>>>>>>>>>>>>>>>> a real error message explaining the issue and not a
>> classical
>>>>>>>>>>>> dependency
>>>>>>>>>>>>>>>> not found while the artifact is in the local repo.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> This is exactly filed here:
>>>>>>>>>>>>>>> http://jira.codehaus.org/browse/MNG-5185
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Arnaud
>>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>>> Jörg
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> If know-how becomes know-where, then knowledge gets nowhere.
>>>>>>>>>>>>>>> [Jörg Hohwiller]
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Olivier Lamy
>>>>>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> -----
>>>>>>>>>>>>> Arnaud Héritier
>>>>>>>>>>>>> http://aheritier.net
>>>>>>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>>>>>>>> Twitter/Skype : aheritier
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> 
>>>>>>>>>>>> Jason
>>>>>>>>>>>> 
>>>>>>>>>>>> ----------------------------------------------------------
>>>>>>>>>>>> Jason van Zyl
>>>>>>>>>>>> Founder & CTO, Sonatype
>>>>>>>>>>>> Founder,  Apache Maven
>>>>>>>>>>>> http://twitter.com/jvanzyl
>>>>>>>>>>>> ---------------------------------------------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> Our achievements speak for themselves. What we have to keep
>> track
>>>>>>>>>>>> of are our failures, discouragements and doubts. We tend to
>> forget
>>>>>>>>>>>> the past difficulties, the many false starts, and the painful
>>>>>>>>>>>> groping. We see our past achievements as the end result of a
>>>>>>>>>>>> clean forward thrust, and our present difficulties as
>>>>>>>>>>>> signs of decline and decay.
>>>>>>>>>>>> 
>>>>>>>>>>>> -- Eric Hoffer, Reflections on the Human Condition
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> -----
>>>>>>>>>>> Arnaud Héritier
>>>>>>>>>>> http://aheritier.net
>>>>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>>>>>> Twitter/Skype : aheritier
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Jeff MAURY
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> "Legacy code" often differs from its suggested alternative by
>>>> actually
>>>>>>>>>> working and scaling.
>>>>>>>>>> - Bjarne Stroustrup
>>>>>>>>>> 
>>>>>>>>>> http://www.jeffmaury.com
>>>>>>>>>> http://riadiscuss.jeffmaury.com
>>>>>>>>>> http://www.twitter.com/jeffmaury
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Baptiste <Batmat> MATHUS - http://batmat.net
>>>>>>>>>> Sauvez un arbre,
>>>>>>>>>> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Jason
>>>>>>>> 
>>>>>>>> ----------------------------------------------------------
>>>>>>>> Jason van Zyl
>>>>>>>> Founder & CTO, Sonatype
>>>>>>>> Founder,  Apache Maven
>>>>>>>> http://twitter.com/jvanzyl
>>>>>>>> ---------------------------------------------------------
>>>>>>>> 
>>>>>>>> To do two things at once is to do neither.
>>>>>>>> 
>>>>>>>> -- Publilius Syrus, Roman slave, first century B.C.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Jason
>>>>>> 
>>>>>> ----------------------------------------------------------
>>>>>> Jason van Zyl
>>>>>> Founder & CTO, Sonatype
>>>>>> Founder,  Apache Maven
>>>>>> http://twitter.com/jvanzyl
>>>>>> ---------------------------------------------------------
>>>>>> 
>>>>>> The modern conservative is engaged in one of man's oldest exercises in
>>>>>> moral philosophy; that is,
>>>>>> the search for a superior moral justification for selfishness.
>>>>>> 
>>>>>> -- John Kenneth Galbraith
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder & CTO, Sonatype
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>> 
>>>> What matters is not ideas, but the people who have them. Good people can
>>>> fix bad ideas, but good ideas can't save bad people.
>>>> 
>>>> -- Paul Graham
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> You are never dedicated to something you have complete confidence in.
>> No one is fanatically shouting that the sun is going to rise tomorrow.
>> They know it is going to rise tomorrow. When people are fanatically
>> dedicated to political or religious faiths or any other kind of
>> dogmas or goals, it's always because these dogmas or
>> goals are in doubt.
>> 
>>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>> 
>> 
>> 
>> 
>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

  -- Jakob Burckhardt

Re: Pain with MNG-5181 (_maven.repositories)

[Romain Manni-Bucau <rm...@gmail.com>]

here it is https://gist.github.com/c07256a99d3b2af322eb

@home i remove the settings.xml in general

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/2/3 Jason van Zyl <ja...@tesla.io>

> Would still be useful if you removed your passwords and sent me both
> configurations, if this is happening to you with this configuration it's
> probably happening to others. If I can give it a quick look I can probably
> tell you why the error is happening or determine if it is, in fact, a bug.
>
> On Feb 3, 2013, at 5:04 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > well nothing special in it (host/port/protocol proxies +
> username/password
> > servers).
> >
> > however i build company projects using enterprise project having as
> > dependencies tomee, could it generate it?
> >
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/2/3 Jason van Zyl <ja...@tesla.io>
> >
> >> Can you send me the configurations?
> >>
> >> If the artifacts are accessible and it fails then that's a bug. But I am
> >> willing to bet one configuration yields a different set of URLs to which
> >> particular artifacts are not accessible. If I can reproduce it then this
> >> will help contribute to an error message that's more useful.
> >>
> >> On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau <rm...@gmail.com>
> >> wrote:
> >>
> >>> I switch my settings and the only differences are:
> >>>
> >>> 1) some server config (i guess that's not important)
> >>> 2) (more important) proxies (host/port)
> >>>
> >>> i don't use mirrorOf.
> >>>
> >>> PS: the issue can happen with tomee trunk so repos are always available
> >>> since the internet is available.
> >>>
> >>> *Romain Manni-Bucau*
> >>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >>> *Blog: **http://rmannibucau.wordpress.com/*<
> >> http://rmannibucau.wordpress.com/>
> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >>> *Github: https://github.com/rmannibucau*
> >>>
> >>>
> >>>
> >>> 2013/2/3 Jason van Zyl <ja...@tesla.io>
> >>>
> >>>> If this is on one machine where you are not changing configurations or
> >>>> locations then something else is wrong as this does not happen for a
> >>>> machine that stays in the same place using the same settings.xml. Do
> you
> >>>> use a mirrorOf in your settings.xml that points to a group repository?
> >> Can
> >>>> you share your configuration? When you encounter this problem next,
> move
> >>>> your whole local repository out of the way (or use
> >>>> -Dmaven.repo.local=/tmp/repo) and you find that the build will fail.
> >>>>
> >>>> When this error occurs it means that the artifacts you're asking for
> are
> >>>> not available in any configured repository. You erase
> >> _maven.repositories
> >>>> file, and Maven does not verify that artifact's existence in the
> remote
> >>>> repository and let's you use the artifact you acquired locally by some
> >>>> other means.
> >>>>
> >>>> This generally happens as a result of switching between configurations
> >>>> which changes the id/url of the repository you are using. You do a
> build
> >>>> against id=repo1(URL1) and get some artifacts and those are recorded
> in
> >> the
> >>>> _maven.repositories files, and then you switch configurations and use
> >>>> id=repo2(URL2) and that repository doesn't have the artifacts you
> >> acquired
> >>>> from id=repo1(URL1).
> >>>>
> >>>> The problem encountered for people flipping between using Central
> >> directly
> >>>> and using a mirrorOf setting with a repository manager is as follows:
> >>>>
> >>>> If you have no mirrorOf setting and you have POMs that contain
> >> repository
> >>>> entries Maven will follow the repositories in the POMs and acquire any
> >>>> dependencies from those repositories listed in the POMs. Now when you
> >> flip
> >>>> to using a mirrorOf setting with a repository manager all those
> requests
> >>>> will be routed through that single URL. If you have not setup the
> >> proxies
> >>>> in your repository manager that correspond to the repositories in the
> >> POMs
> >>>> the build will fail because those artifacts are not accessible to the
> >>>> repository manager.
> >>>>
> >>>> On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> >>>> wrote:
> >>>>
> >>>>> Hi guys,
> >>>>>
> >>>>> Not sure it is linked or not (i read the thread lately) but at work
> we
> >>>> use
> >>>>> a proxy and not at "home" and i often have to remove _maven.repo
> files
> >>>>> (both ways) to make my build work again...that's an everyday pain.
> >>>>> Le 3 févr. 2013 21:41, "Jason van Zyl" <ja...@tesla.io> a écrit :
> >>>>>
> >>>>>>
> >>>>>> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
> >>>>>>
> >>>>>>> +1.
> >>>>>>>
> >>>>>>> Though the feature seems interesting, it should have had its own
> >>>>>>> advertisement while being introduced.
> >>>>>>> Even after re-reading
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
> >>>>>>> I'm
> >>>>>>> still unsure about where/when it would bite me.
> >>>>>>
> >>>>>> Does this make sense to you?
> >>>>>>
> >>>>>> ---
> >>>>>>
> >>>>>> h1. Enhanced Remote Repository Support
> >>>>>>
> >>>>>> The feature verifies that the remote repositories configured for the
> >>>>>> current build can be used to successfully resolve the artifact in
> >>>> question.
> >>>>>> If you retrieved an artifact in the past from Central and now
> changed
> >>>> your
> >>>>>> build to only know about Nexus and it doesn't have any knowledge of
> >> that
> >>>>>> artifact then the build is going to fail. Put differently, if you
> >> purged
> >>>>>> your local repo, your build won't work either. Neglecting offline
> >> mode,
> >>>> the
> >>>>>> goal is to ensure that the resolution works if it could be performed
> >>>> using
> >>>>>> a clean local repo with the current configuration. Giving confidence
> >>>> that
> >>>>>> co-workers can reproduce the build and not depend on some artifact
> >>>>>> magically being pulled down into your local repository in the past
> >>>> which is
> >>>>>> nowhere to be found in the configured remote repository.
> >>>>>>
> >>>>>> ---
> >>>>>>
> >>>>>> And would you want that off by default?
> >>>>>>
> >>>>>>> As I know and like Maven quite well, if I was bitten by that, I
> might
> >>>> do
> >>>>>>> some reseach and find jiras etc.
> >>>>>>>
> >>>>>>> Others might just struggle to make it work and grow the maven
> bashing
> >>>>>> group
> >>>>>>> as Jeff said.
> >>>>>>>
> >>>>>>>
> >>>>>>> 2013/2/1 Jeff MAURY <je...@jeffmaury.com>
> >>>>>>>
> >>>>>>>> +1 on Arnaud's comments.
> >>>>>>>> The main problem with this "feature" is that it is not documented
> >>>> thus I
> >>>>>>>> can't explain the real reason why Maven download several times
> >>>> released
> >>>>>>>> artifacts and this causes members of the Maven bashing group to
> grow
> >>>>>>>>
> >>>>>>>> Jeff
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <
> >> aheritier@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> My position was to propose the low cost possible solution to
> have a
> >>>>>> quick
> >>>>>>>>> fix and not to wait for months.
> >>>>>>>>> If it could be fixed/configurable in aether it may be the
> solution
> >> to
> >>>>>>>>> follow but I'm not sure about the status of this 3rd party
> project
> >>>>>>>> (eclipse
> >>>>>>>>> migration ...) on which we don't have the hand.
> >>>>>>>>> Seriously I helped and lost MANY hours with this problem because
> it
> >>>> is
> >>>>>>>> hard
> >>>>>>>>> to diagnose.
> >>>>>>>>> I'm sure that many people abandoned to try to understand and just
> >>>>>> dropped
> >>>>>>>>> their local repo or decided to downgraded to m2 (or to switch to
> >>>>>> another
> >>>>>>>>> tool).
> >>>>>>>>> I think we can have a lot of similar feedbacks.
> >>>>>>>>> The worst thing is to have another thing that users don't
> >> understand
> >>>>>>>> (lake
> >>>>>>>>> of documentation ? communication ?)
> >>>>>>>>> The side effect is that changing a repository id (or mirror id)
> >> makes
> >>>>>>>> maven
> >>>>>>>>> to re-download all the earth (while we are claiming from the
> >>>> beginning
> >>>>>>>> that
> >>>>>>>>> Maven won't never download twice a release).
> >>>>>>>>> And when the remote artifact just disappeared it is just a
> >> nightmare
> >>>>>> due
> >>>>>>>> to
> >>>>>>>>> the lake of correct logs and this case is easy to have.
> >>>>>>>>> For example in my company I have a profile to let people DL
> >> artifacts
> >>>>>>>> from
> >>>>>>>>> staging repositories (thus these are releases). It happened that
> >> they
> >>>>>>>>> activated it once to test a build and then they rebuild the
> project
> >>>>>>>> without
> >>>>>>>>> the profile (thinking the artifact is in the local repo) and it
> >> fails
> >>>>>> ...
> >>>>>>>>>
> >>>>>>>>> Sincerely I think I had my worst headaches with maven due to this
> >> bug
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io>
> >>>> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <
> aheritier@gmail.com
> >>>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi Olivier,
> >>>>>>>>>>>
> >>>>>>>>>>> Thx a lot for the fix. It will help a lot the community.
> >>>>>>>>>>> But from my point of view it's perhaps not yet enough.
> >>>>>>>>>>> We should :
> >>>>>>>>>>> 1/ change the default behavior to deactivate this control which
> >> is
> >>>>>>>>>>> difficult to understand
> >>>>>>>>>>
> >>>>>>>>>> I disagree. We may want to change it slightly but it's only a
> >>>> problem
> >>>>>>>> for
> >>>>>>>>>> people who flip between Maven a repository manager and without
> but
> >>>>>> it's
> >>>>>>>>> to
> >>>>>>>>>> ensure the identity of a component. I haven't seen a huge number
> >> of
> >>>>>>>>>> complaints. I do not want to turn this off. Improve it, sure,
> but
> >>>>>>>> turning
> >>>>>>>>>> it off by default I believe is not the right thing to do.
> >>>>>>>>>>
> >>>>>>>>>>> 2/ change the error message when this control is activated to
> >>>>>>>> clearly
> >>>>>>>>>>> explain that the problem comes from the unavailability of the
> >>>>>>>> artifact
> >>>>>>>>> on
> >>>>>>>>>>> its original remote repo.
> >>>>>>>>>>>
> >>>>>>>>>>> For me 1/ is mandatory and 2/ a nice to have
> >>>>>>>>>>>
> >>>>>>>>>>> WDYT ?
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <
> olamy@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I have pushed a fix for that.
> >>>>>>>>>>>> Now you can desactivate the enhanced local repository using:
> >>>>>>>>>>>> * new cli option: -slrm,--simple-local-repository-manager
> >>>>>>>>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
> >>>>>>>>>>>>
> >>>>>>>>>>>> will be available for testing here
> >>>>>>>>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
> >>>>>>>>>>>>> Hi Arnaud,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> +1 to consider the current behavior as a bug.
> >>>>>>>>>>>>>> We should be able to deactivate it easily (and perhaps to
> have
> >>>> it
> >>>>>>>>> off
> >>>>>>>>>> by
> >>>>>>>>>>>>>> default to activate it only on CI servers)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> :)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> and we should take care to have
> >>>>>>>>>>>>>> a real error message explaining the issue and not a
> classical
> >>>>>>>>>> dependency
> >>>>>>>>>>>>>> not found while the artifact is in the local repo.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This is exactly filed here:
> >>>>>>>>>>>>> http://jira.codehaus.org/browse/MNG-5185
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Arnaud
> >>>>>>>>>>>>> Cheers
> >>>>>>>>>>>>> Jörg
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> If know-how becomes know-where, then knowledge gets nowhere.
> >>>>>>>>>>>>> [Jörg Hohwiller]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Olivier Lamy
> >>>>>>>>>>>> Talend: http://coders.talend.com
> >>>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> -----
> >>>>>>>>>>> Arnaud Héritier
> >>>>>>>>>>> http://aheritier.net
> >>>>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
> >>>>>>>>>>> Twitter/Skype : aheritier
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>
> >>>>>>>>>> Jason
> >>>>>>>>>>
> >>>>>>>>>> ----------------------------------------------------------
> >>>>>>>>>> Jason van Zyl
> >>>>>>>>>> Founder & CTO, Sonatype
> >>>>>>>>>> Founder,  Apache Maven
> >>>>>>>>>> http://twitter.com/jvanzyl
> >>>>>>>>>> ---------------------------------------------------------
> >>>>>>>>>>
> >>>>>>>>>> Our achievements speak for themselves. What we have to keep
> track
> >>>>>>>>>> of are our failures, discouragements and doubts. We tend to
> forget
> >>>>>>>>>> the past difficulties, the many false starts, and the painful
> >>>>>>>>>> groping. We see our past achievements as the end result of a
> >>>>>>>>>> clean forward thrust, and our present difficulties as
> >>>>>>>>>> signs of decline and decay.
> >>>>>>>>>>
> >>>>>>>>>> -- Eric Hoffer, Reflections on the Human Condition
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> -----
> >>>>>>>>> Arnaud Héritier
> >>>>>>>>> http://aheritier.net
> >>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
> >>>>>>>>> Twitter/Skype : aheritier
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Jeff MAURY
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> "Legacy code" often differs from its suggested alternative by
> >> actually
> >>>>>>>> working and scaling.
> >>>>>>>> - Bjarne Stroustrup
> >>>>>>>>
> >>>>>>>> http://www.jeffmaury.com
> >>>>>>>> http://riadiscuss.jeffmaury.com
> >>>>>>>> http://www.twitter.com/jeffmaury
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Baptiste <Batmat> MATHUS - http://batmat.net
> >>>>>>>> Sauvez un arbre,
> >>>>>>>> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Jason
> >>>>>>
> >>>>>> ----------------------------------------------------------
> >>>>>> Jason van Zyl
> >>>>>> Founder & CTO, Sonatype
> >>>>>> Founder,  Apache Maven
> >>>>>> http://twitter.com/jvanzyl
> >>>>>> ---------------------------------------------------------
> >>>>>>
> >>>>>> To do two things at once is to do neither.
> >>>>>>
> >>>>>> -- Publilius Syrus, Roman slave, first century B.C.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jason
> >>>>
> >>>> ----------------------------------------------------------
> >>>> Jason van Zyl
> >>>> Founder & CTO, Sonatype
> >>>> Founder,  Apache Maven
> >>>> http://twitter.com/jvanzyl
> >>>> ---------------------------------------------------------
> >>>>
> >>>> The modern conservative is engaged in one of man's oldest exercises in
> >>>> moral philosophy; that is,
> >>>> the search for a superior moral justification for selfishness.
> >>>>
> >>>> -- John Kenneth Galbraith
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder & CTO, Sonatype
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >>
> >> What matters is not ideas, but the people who have them. Good people can
> >> fix bad ideas, but good ideas can't save bad people.
> >>
> >> -- Paul Graham
> >>
> >>
> >>
> >>
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
>
>   -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>
>
>
>
>
>

Re: Pain with MNG-5181 (_maven.repositories)

[Jason van Zyl <ja...@tesla.io>]

Would still be useful if you removed your passwords and sent me both configurations, if this is happening to you with this configuration it's probably happening to others. If I can give it a quick look I can probably tell you why the error is happening or determine if it is, in fact, a bug.

On Feb 3, 2013, at 5:04 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:

> well nothing special in it (host/port/protocol proxies + username/password
> servers).
> 
> however i build company projects using enterprise project having as
> dependencies tomee, could it generate it?
> 
> 
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
> 
> 
> 
> 2013/2/3 Jason van Zyl <ja...@tesla.io>
> 
>> Can you send me the configurations?
>> 
>> If the artifacts are accessible and it fails then that's a bug. But I am
>> willing to bet one configuration yields a different set of URLs to which
>> particular artifacts are not accessible. If I can reproduce it then this
>> will help contribute to an error message that's more useful.
>> 
>> On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>> 
>>> I switch my settings and the only differences are:
>>> 
>>> 1) some server config (i guess that's not important)
>>> 2) (more important) proxies (host/port)
>>> 
>>> i don't use mirrorOf.
>>> 
>>> PS: the issue can happen with tomee trunk so repos are always available
>>> since the internet is available.
>>> 
>>> *Romain Manni-Bucau*
>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>>> *Blog: **http://rmannibucau.wordpress.com/*<
>> http://rmannibucau.wordpress.com/>
>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>> *Github: https://github.com/rmannibucau*
>>> 
>>> 
>>> 
>>> 2013/2/3 Jason van Zyl <ja...@tesla.io>
>>> 
>>>> If this is on one machine where you are not changing configurations or
>>>> locations then something else is wrong as this does not happen for a
>>>> machine that stays in the same place using the same settings.xml. Do you
>>>> use a mirrorOf in your settings.xml that points to a group repository?
>> Can
>>>> you share your configuration? When you encounter this problem next, move
>>>> your whole local repository out of the way (or use
>>>> -Dmaven.repo.local=/tmp/repo) and you find that the build will fail.
>>>> 
>>>> When this error occurs it means that the artifacts you're asking for are
>>>> not available in any configured repository. You erase
>> _maven.repositories
>>>> file, and Maven does not verify that artifact's existence in the remote
>>>> repository and let's you use the artifact you acquired locally by some
>>>> other means.
>>>> 
>>>> This generally happens as a result of switching between configurations
>>>> which changes the id/url of the repository you are using. You do a build
>>>> against id=repo1(URL1) and get some artifacts and those are recorded in
>> the
>>>> _maven.repositories files, and then you switch configurations and use
>>>> id=repo2(URL2) and that repository doesn't have the artifacts you
>> acquired
>>>> from id=repo1(URL1).
>>>> 
>>>> The problem encountered for people flipping between using Central
>> directly
>>>> and using a mirrorOf setting with a repository manager is as follows:
>>>> 
>>>> If you have no mirrorOf setting and you have POMs that contain
>> repository
>>>> entries Maven will follow the repositories in the POMs and acquire any
>>>> dependencies from those repositories listed in the POMs. Now when you
>> flip
>>>> to using a mirrorOf setting with a repository manager all those requests
>>>> will be routed through that single URL. If you have not setup the
>> proxies
>>>> in your repository manager that correspond to the repositories in the
>> POMs
>>>> the build will fail because those artifacts are not accessible to the
>>>> repository manager.
>>>> 
>>>> On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau <rm...@gmail.com>
>>>> wrote:
>>>> 
>>>>> Hi guys,
>>>>> 
>>>>> Not sure it is linked or not (i read the thread lately) but at work we
>>>> use
>>>>> a proxy and not at "home" and i often have to remove _maven.repo files
>>>>> (both ways) to make my build work again...that's an everyday pain.
>>>>> Le 3 févr. 2013 21:41, "Jason van Zyl" <ja...@tesla.io> a écrit :
>>>>> 
>>>>>> 
>>>>>> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
>>>>>> 
>>>>>>> +1.
>>>>>>> 
>>>>>>> Though the feature seems interesting, it should have had its own
>>>>>>> advertisement while being introduced.
>>>>>>> Even after re-reading
>>>>>>> 
>>>>>> 
>>>> 
>> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
>>>>>>> I'm
>>>>>>> still unsure about where/when it would bite me.
>>>>>> 
>>>>>> Does this make sense to you?
>>>>>> 
>>>>>> ---
>>>>>> 
>>>>>> h1. Enhanced Remote Repository Support
>>>>>> 
>>>>>> The feature verifies that the remote repositories configured for the
>>>>>> current build can be used to successfully resolve the artifact in
>>>> question.
>>>>>> If you retrieved an artifact in the past from Central and now changed
>>>> your
>>>>>> build to only know about Nexus and it doesn't have any knowledge of
>> that
>>>>>> artifact then the build is going to fail. Put differently, if you
>> purged
>>>>>> your local repo, your build won't work either. Neglecting offline
>> mode,
>>>> the
>>>>>> goal is to ensure that the resolution works if it could be performed
>>>> using
>>>>>> a clean local repo with the current configuration. Giving confidence
>>>> that
>>>>>> co-workers can reproduce the build and not depend on some artifact
>>>>>> magically being pulled down into your local repository in the past
>>>> which is
>>>>>> nowhere to be found in the configured remote repository.
>>>>>> 
>>>>>> ---
>>>>>> 
>>>>>> And would you want that off by default?
>>>>>> 
>>>>>>> As I know and like Maven quite well, if I was bitten by that, I might
>>>> do
>>>>>>> some reseach and find jiras etc.
>>>>>>> 
>>>>>>> Others might just struggle to make it work and grow the maven bashing
>>>>>> group
>>>>>>> as Jeff said.
>>>>>>> 
>>>>>>> 
>>>>>>> 2013/2/1 Jeff MAURY <je...@jeffmaury.com>
>>>>>>> 
>>>>>>>> +1 on Arnaud's comments.
>>>>>>>> The main problem with this "feature" is that it is not documented
>>>> thus I
>>>>>>>> can't explain the real reason why Maven download several times
>>>> released
>>>>>>>> artifacts and this causes members of the Maven bashing group to grow
>>>>>>>> 
>>>>>>>> Jeff
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <
>> aheritier@gmail.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> My position was to propose the low cost possible solution to have a
>>>>>> quick
>>>>>>>>> fix and not to wait for months.
>>>>>>>>> If it could be fixed/configurable in aether it may be the solution
>> to
>>>>>>>>> follow but I'm not sure about the status of this 3rd party project
>>>>>>>> (eclipse
>>>>>>>>> migration ...) on which we don't have the hand.
>>>>>>>>> Seriously I helped and lost MANY hours with this problem because it
>>>> is
>>>>>>>> hard
>>>>>>>>> to diagnose.
>>>>>>>>> I'm sure that many people abandoned to try to understand and just
>>>>>> dropped
>>>>>>>>> their local repo or decided to downgraded to m2 (or to switch to
>>>>>> another
>>>>>>>>> tool).
>>>>>>>>> I think we can have a lot of similar feedbacks.
>>>>>>>>> The worst thing is to have another thing that users don't
>> understand
>>>>>>>> (lake
>>>>>>>>> of documentation ? communication ?)
>>>>>>>>> The side effect is that changing a repository id (or mirror id)
>> makes
>>>>>>>> maven
>>>>>>>>> to re-download all the earth (while we are claiming from the
>>>> beginning
>>>>>>>> that
>>>>>>>>> Maven won't never download twice a release).
>>>>>>>>> And when the remote artifact just disappeared it is just a
>> nightmare
>>>>>> due
>>>>>>>> to
>>>>>>>>> the lake of correct logs and this case is easy to have.
>>>>>>>>> For example in my company I have a profile to let people DL
>> artifacts
>>>>>>>> from
>>>>>>>>> staging repositories (thus these are releases). It happened that
>> they
>>>>>>>>> activated it once to test a build and then they rebuild the project
>>>>>>>> without
>>>>>>>>> the profile (thinking the artifact is in the local repo) and it
>> fails
>>>>>> ...
>>>>>>>>> 
>>>>>>>>> Sincerely I think I had my worst headaches with maven due to this
>> bug
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io>
>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <aheritier@gmail.com
>>> 
>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi Olivier,
>>>>>>>>>>> 
>>>>>>>>>>> Thx a lot for the fix. It will help a lot the community.
>>>>>>>>>>> But from my point of view it's perhaps not yet enough.
>>>>>>>>>>> We should :
>>>>>>>>>>> 1/ change the default behavior to deactivate this control which
>> is
>>>>>>>>>>> difficult to understand
>>>>>>>>>> 
>>>>>>>>>> I disagree. We may want to change it slightly but it's only a
>>>> problem
>>>>>>>> for
>>>>>>>>>> people who flip between Maven a repository manager and without but
>>>>>> it's
>>>>>>>>> to
>>>>>>>>>> ensure the identity of a component. I haven't seen a huge number
>> of
>>>>>>>>>> complaints. I do not want to turn this off. Improve it, sure, but
>>>>>>>> turning
>>>>>>>>>> it off by default I believe is not the right thing to do.
>>>>>>>>>> 
>>>>>>>>>>> 2/ change the error message when this control is activated to
>>>>>>>> clearly
>>>>>>>>>>> explain that the problem comes from the unavailability of the
>>>>>>>> artifact
>>>>>>>>> on
>>>>>>>>>>> its original remote repo.
>>>>>>>>>>> 
>>>>>>>>>>> For me 1/ is mandatory and 2/ a nice to have
>>>>>>>>>>> 
>>>>>>>>>>> WDYT ?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> I have pushed a fix for that.
>>>>>>>>>>>> Now you can desactivate the enhanced local repository using:
>>>>>>>>>>>> * new cli option: -slrm,--simple-local-repository-manager
>>>>>>>>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
>>>>>>>>>>>> 
>>>>>>>>>>>> will be available for testing here
>>>>>>>>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
>>>>>>>>>>>>> Hi Arnaud,
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> +1 to consider the current behavior as a bug.
>>>>>>>>>>>>>> We should be able to deactivate it easily (and perhaps to have
>>>> it
>>>>>>>>> off
>>>>>>>>>> by
>>>>>>>>>>>>>> default to activate it only on CI servers)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> :)
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> and we should take care to have
>>>>>>>>>>>>>> a real error message explaining the issue and not a classical
>>>>>>>>>> dependency
>>>>>>>>>>>>>> not found while the artifact is in the local repo.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> This is exactly filed here:
>>>>>>>>>>>>> http://jira.codehaus.org/browse/MNG-5185
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Arnaud
>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>> Jörg
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> If know-how becomes know-where, then knowledge gets nowhere.
>>>>>>>>>>>>> [Jörg Hohwiller]
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Olivier Lamy
>>>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>> 
>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> -----
>>>>>>>>>>> Arnaud Héritier
>>>>>>>>>>> http://aheritier.net
>>>>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>>>>>> Twitter/Skype : aheritier
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> 
>>>>>>>>>> Jason
>>>>>>>>>> 
>>>>>>>>>> ----------------------------------------------------------
>>>>>>>>>> Jason van Zyl
>>>>>>>>>> Founder & CTO, Sonatype
>>>>>>>>>> Founder,  Apache Maven
>>>>>>>>>> http://twitter.com/jvanzyl
>>>>>>>>>> ---------------------------------------------------------
>>>>>>>>>> 
>>>>>>>>>> Our achievements speak for themselves. What we have to keep track
>>>>>>>>>> of are our failures, discouragements and doubts. We tend to forget
>>>>>>>>>> the past difficulties, the many false starts, and the painful
>>>>>>>>>> groping. We see our past achievements as the end result of a
>>>>>>>>>> clean forward thrust, and our present difficulties as
>>>>>>>>>> signs of decline and decay.
>>>>>>>>>> 
>>>>>>>>>> -- Eric Hoffer, Reflections on the Human Condition
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> -----
>>>>>>>>> Arnaud Héritier
>>>>>>>>> http://aheritier.net
>>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>>>> Twitter/Skype : aheritier
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Jeff MAURY
>>>>>>>> 
>>>>>>>> 
>>>>>>>> "Legacy code" often differs from its suggested alternative by
>> actually
>>>>>>>> working and scaling.
>>>>>>>> - Bjarne Stroustrup
>>>>>>>> 
>>>>>>>> http://www.jeffmaury.com
>>>>>>>> http://riadiscuss.jeffmaury.com
>>>>>>>> http://www.twitter.com/jeffmaury
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Baptiste <Batmat> MATHUS - http://batmat.net
>>>>>>>> Sauvez un arbre,
>>>>>>>> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Jason
>>>>>> 
>>>>>> ----------------------------------------------------------
>>>>>> Jason van Zyl
>>>>>> Founder & CTO, Sonatype
>>>>>> Founder,  Apache Maven
>>>>>> http://twitter.com/jvanzyl
>>>>>> ---------------------------------------------------------
>>>>>> 
>>>>>> To do two things at once is to do neither.
>>>>>> 
>>>>>> -- Publilius Syrus, Roman slave, first century B.C.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder & CTO, Sonatype
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>> 
>>>> The modern conservative is engaged in one of man's oldest exercises in
>>>> moral philosophy; that is,
>>>> the search for a superior moral justification for selfishness.
>>>> 
>>>> -- John Kenneth Galbraith
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> What matters is not ideas, but the people who have them. Good people can
>> fix bad ideas, but good ideas can't save bad people.
>> 
>> -- Paul Graham
>> 
>> 
>> 
>> 
>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of 
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

Re: Pain with MNG-5181 (_maven.repositories)

[Romain Manni-Bucau <rm...@gmail.com>]

well nothing special in it (host/port/protocol proxies + username/password
servers).

however i build company projects using enterprise project having as
dependencies tomee, could it generate it?


*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/2/3 Jason van Zyl <ja...@tesla.io>

> Can you send me the configurations?
>
> If the artifacts are accessible and it fails then that's a bug. But I am
> willing to bet one configuration yields a different set of URLs to which
> particular artifacts are not accessible. If I can reproduce it then this
> will help contribute to an error message that's more useful.
>
> On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > I switch my settings and the only differences are:
> >
> > 1) some server config (i guess that's not important)
> > 2) (more important) proxies (host/port)
> >
> > i don't use mirrorOf.
> >
> > PS: the issue can happen with tomee trunk so repos are always available
> > since the internet is available.
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/2/3 Jason van Zyl <ja...@tesla.io>
> >
> >> If this is on one machine where you are not changing configurations or
> >> locations then something else is wrong as this does not happen for a
> >> machine that stays in the same place using the same settings.xml. Do you
> >> use a mirrorOf in your settings.xml that points to a group repository?
> Can
> >> you share your configuration? When you encounter this problem next, move
> >> your whole local repository out of the way (or use
> >> -Dmaven.repo.local=/tmp/repo) and you find that the build will fail.
> >>
> >> When this error occurs it means that the artifacts you're asking for are
> >> not available in any configured repository. You erase
> _maven.repositories
> >> file, and Maven does not verify that artifact's existence in the remote
> >> repository and let's you use the artifact you acquired locally by some
> >> other means.
> >>
> >> This generally happens as a result of switching between configurations
> >> which changes the id/url of the repository you are using. You do a build
> >> against id=repo1(URL1) and get some artifacts and those are recorded in
> the
> >> _maven.repositories files, and then you switch configurations and use
> >> id=repo2(URL2) and that repository doesn't have the artifacts you
> acquired
> >> from id=repo1(URL1).
> >>
> >> The problem encountered for people flipping between using Central
> directly
> >> and using a mirrorOf setting with a repository manager is as follows:
> >>
> >> If you have no mirrorOf setting and you have POMs that contain
> repository
> >> entries Maven will follow the repositories in the POMs and acquire any
> >> dependencies from those repositories listed in the POMs. Now when you
> flip
> >> to using a mirrorOf setting with a repository manager all those requests
> >> will be routed through that single URL. If you have not setup the
> proxies
> >> in your repository manager that correspond to the repositories in the
> POMs
> >> the build will fail because those artifacts are not accessible to the
> >> repository manager.
> >>
> >> On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau <rm...@gmail.com>
> >> wrote:
> >>
> >>> Hi guys,
> >>>
> >>> Not sure it is linked or not (i read the thread lately) but at work we
> >> use
> >>> a proxy and not at "home" and i often have to remove _maven.repo files
> >>> (both ways) to make my build work again...that's an everyday pain.
> >>> Le 3 févr. 2013 21:41, "Jason van Zyl" <ja...@tesla.io> a écrit :
> >>>
> >>>>
> >>>> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
> >>>>
> >>>>> +1.
> >>>>>
> >>>>> Though the feature seems interesting, it should have had its own
> >>>>> advertisement while being introduced.
> >>>>> Even after re-reading
> >>>>>
> >>>>
> >>
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
> >>>>> I'm
> >>>>> still unsure about where/when it would bite me.
> >>>>
> >>>> Does this make sense to you?
> >>>>
> >>>> ---
> >>>>
> >>>> h1. Enhanced Remote Repository Support
> >>>>
> >>>> The feature verifies that the remote repositories configured for the
> >>>> current build can be used to successfully resolve the artifact in
> >> question.
> >>>> If you retrieved an artifact in the past from Central and now changed
> >> your
> >>>> build to only know about Nexus and it doesn't have any knowledge of
> that
> >>>> artifact then the build is going to fail. Put differently, if you
> purged
> >>>> your local repo, your build won't work either. Neglecting offline
> mode,
> >> the
> >>>> goal is to ensure that the resolution works if it could be performed
> >> using
> >>>> a clean local repo with the current configuration. Giving confidence
> >> that
> >>>> co-workers can reproduce the build and not depend on some artifact
> >>>> magically being pulled down into your local repository in the past
> >> which is
> >>>> nowhere to be found in the configured remote repository.
> >>>>
> >>>> ---
> >>>>
> >>>> And would you want that off by default?
> >>>>
> >>>>> As I know and like Maven quite well, if I was bitten by that, I might
> >> do
> >>>>> some reseach and find jiras etc.
> >>>>>
> >>>>> Others might just struggle to make it work and grow the maven bashing
> >>>> group
> >>>>> as Jeff said.
> >>>>>
> >>>>>
> >>>>> 2013/2/1 Jeff MAURY <je...@jeffmaury.com>
> >>>>>
> >>>>>> +1 on Arnaud's comments.
> >>>>>> The main problem with this "feature" is that it is not documented
> >> thus I
> >>>>>> can't explain the real reason why Maven download several times
> >> released
> >>>>>> artifacts and this causes members of the Maven bashing group to grow
> >>>>>>
> >>>>>> Jeff
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <
> aheritier@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> My position was to propose the low cost possible solution to have a
> >>>> quick
> >>>>>>> fix and not to wait for months.
> >>>>>>> If it could be fixed/configurable in aether it may be the solution
> to
> >>>>>>> follow but I'm not sure about the status of this 3rd party project
> >>>>>> (eclipse
> >>>>>>> migration ...) on which we don't have the hand.
> >>>>>>> Seriously I helped and lost MANY hours with this problem because it
> >> is
> >>>>>> hard
> >>>>>>> to diagnose.
> >>>>>>> I'm sure that many people abandoned to try to understand and just
> >>>> dropped
> >>>>>>> their local repo or decided to downgraded to m2 (or to switch to
> >>>> another
> >>>>>>> tool).
> >>>>>>> I think we can have a lot of similar feedbacks.
> >>>>>>> The worst thing is to have another thing that users don't
> understand
> >>>>>> (lake
> >>>>>>> of documentation ? communication ?)
> >>>>>>> The side effect is that changing a repository id (or mirror id)
> makes
> >>>>>> maven
> >>>>>>> to re-download all the earth (while we are claiming from the
> >> beginning
> >>>>>> that
> >>>>>>> Maven won't never download twice a release).
> >>>>>>> And when the remote artifact just disappeared it is just a
> nightmare
> >>>> due
> >>>>>> to
> >>>>>>> the lake of correct logs and this case is easy to have.
> >>>>>>> For example in my company I have a profile to let people DL
> artifacts
> >>>>>> from
> >>>>>>> staging repositories (thus these are releases). It happened that
> they
> >>>>>>> activated it once to test a build and then they rebuild the project
> >>>>>> without
> >>>>>>> the profile (thinking the artifact is in the local repo) and it
> fails
> >>>> ...
> >>>>>>>
> >>>>>>> Sincerely I think I had my worst headaches with maven due to this
> bug
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io>
> >> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <aheritier@gmail.com
> >
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Olivier,
> >>>>>>>>>
> >>>>>>>>> Thx a lot for the fix. It will help a lot the community.
> >>>>>>>>> But from my point of view it's perhaps not yet enough.
> >>>>>>>>> We should :
> >>>>>>>>> 1/ change the default behavior to deactivate this control which
> is
> >>>>>>>>> difficult to understand
> >>>>>>>>
> >>>>>>>> I disagree. We may want to change it slightly but it's only a
> >> problem
> >>>>>> for
> >>>>>>>> people who flip between Maven a repository manager and without but
> >>>> it's
> >>>>>>> to
> >>>>>>>> ensure the identity of a component. I haven't seen a huge number
> of
> >>>>>>>> complaints. I do not want to turn this off. Improve it, sure, but
> >>>>>> turning
> >>>>>>>> it off by default I believe is not the right thing to do.
> >>>>>>>>
> >>>>>>>>> 2/ change the error message when this control is activated to
> >>>>>> clearly
> >>>>>>>>> explain that the problem comes from the unavailability of the
> >>>>>> artifact
> >>>>>>> on
> >>>>>>>>> its original remote repo.
> >>>>>>>>>
> >>>>>>>>> For me 1/ is mandatory and 2/ a nice to have
> >>>>>>>>>
> >>>>>>>>> WDYT ?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I have pushed a fix for that.
> >>>>>>>>>> Now you can desactivate the enhanced local repository using:
> >>>>>>>>>> * new cli option: -slrm,--simple-local-repository-manager
> >>>>>>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
> >>>>>>>>>>
> >>>>>>>>>> will be available for testing here
> >>>>>>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
> >>>>>>>>>>> Hi Arnaud,
> >>>>>>>>>>>
> >>>>>>>>>>>> +1 to consider the current behavior as a bug.
> >>>>>>>>>>>> We should be able to deactivate it easily (and perhaps to have
> >> it
> >>>>>>> off
> >>>>>>>> by
> >>>>>>>>>>>> default to activate it only on CI servers)
> >>>>>>>>>>>
> >>>>>>>>>>> :)
> >>>>>>>>>>>
> >>>>>>>>>>>> and we should take care to have
> >>>>>>>>>>>> a real error message explaining the issue and not a classical
> >>>>>>>> dependency
> >>>>>>>>>>>> not found while the artifact is in the local repo.
> >>>>>>>>>>>
> >>>>>>>>>>> This is exactly filed here:
> >>>>>>>>>>> http://jira.codehaus.org/browse/MNG-5185
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Arnaud
> >>>>>>>>>>> Cheers
> >>>>>>>>>>> Jörg
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> If know-how becomes know-where, then knowledge gets nowhere.
> >>>>>>>>>>> [Jörg Hohwiller]
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Olivier Lamy
> >>>>>>>>>> Talend: http://coders.talend.com
> >>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> -----
> >>>>>>>>> Arnaud Héritier
> >>>>>>>>> http://aheritier.net
> >>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
> >>>>>>>>> Twitter/Skype : aheritier
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Jason
> >>>>>>>>
> >>>>>>>> ----------------------------------------------------------
> >>>>>>>> Jason van Zyl
> >>>>>>>> Founder & CTO, Sonatype
> >>>>>>>> Founder,  Apache Maven
> >>>>>>>> http://twitter.com/jvanzyl
> >>>>>>>> ---------------------------------------------------------
> >>>>>>>>
> >>>>>>>> Our achievements speak for themselves. What we have to keep track
> >>>>>>>> of are our failures, discouragements and doubts. We tend to forget
> >>>>>>>> the past difficulties, the many false starts, and the painful
> >>>>>>>> groping. We see our past achievements as the end result of a
> >>>>>>>> clean forward thrust, and our present difficulties as
> >>>>>>>> signs of decline and decay.
> >>>>>>>>
> >>>>>>>> -- Eric Hoffer, Reflections on the Human Condition
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> -----
> >>>>>>> Arnaud Héritier
> >>>>>>> http://aheritier.net
> >>>>>>> Mail/GTalk: aheritier AT gmail DOT com
> >>>>>>> Twitter/Skype : aheritier
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Jeff MAURY
> >>>>>>
> >>>>>>
> >>>>>> "Legacy code" often differs from its suggested alternative by
> actually
> >>>>>> working and scaling.
> >>>>>> - Bjarne Stroustrup
> >>>>>>
> >>>>>> http://www.jeffmaury.com
> >>>>>> http://riadiscuss.jeffmaury.com
> >>>>>> http://www.twitter.com/jeffmaury
> >>>>>>
> >>>>>> --
> >>>>>> Baptiste <Batmat> MATHUS - http://batmat.net
> >>>>>> Sauvez un arbre,
> >>>>>> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jason
> >>>>
> >>>> ----------------------------------------------------------
> >>>> Jason van Zyl
> >>>> Founder & CTO, Sonatype
> >>>> Founder,  Apache Maven
> >>>> http://twitter.com/jvanzyl
> >>>> ---------------------------------------------------------
> >>>>
> >>>> To do two things at once is to do neither.
> >>>>
> >>>> -- Publilius Syrus, Roman slave, first century B.C.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder & CTO, Sonatype
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >>
> >> The modern conservative is engaged in one of man's oldest exercises in
> >> moral philosophy; that is,
> >> the search for a superior moral justification for selfishness.
> >>
> >> -- John Kenneth Galbraith
> >>
> >>
> >>
> >>
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> What matters is not ideas, but the people who have them. Good people can
> fix bad ideas, but good ideas can't save bad people.
>
>  -- Paul Graham
>
>
>
>
>
>

Re: Pain with MNG-5181 (_maven.repositories)

[Jason van Zyl <ja...@tesla.io>]

Can you send me the configurations?

If the artifacts are accessible and it fails then that's a bug. But I am willing to bet one configuration yields a different set of URLs to which particular artifacts are not accessible. If I can reproduce it then this will help contribute to an error message that's more useful.

On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:

> I switch my settings and the only differences are:
> 
> 1) some server config (i guess that's not important)
> 2) (more important) proxies (host/port)
> 
> i don't use mirrorOf.
> 
> PS: the issue can happen with tomee trunk so repos are always available
> since the internet is available.
> 
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
> 
> 
> 
> 2013/2/3 Jason van Zyl <ja...@tesla.io>
> 
>> If this is on one machine where you are not changing configurations or
>> locations then something else is wrong as this does not happen for a
>> machine that stays in the same place using the same settings.xml. Do you
>> use a mirrorOf in your settings.xml that points to a group repository? Can
>> you share your configuration? When you encounter this problem next, move
>> your whole local repository out of the way (or use
>> -Dmaven.repo.local=/tmp/repo) and you find that the build will fail.
>> 
>> When this error occurs it means that the artifacts you're asking for are
>> not available in any configured repository. You erase _maven.repositories
>> file, and Maven does not verify that artifact's existence in the remote
>> repository and let's you use the artifact you acquired locally by some
>> other means.
>> 
>> This generally happens as a result of switching between configurations
>> which changes the id/url of the repository you are using. You do a build
>> against id=repo1(URL1) and get some artifacts and those are recorded in the
>> _maven.repositories files, and then you switch configurations and use
>> id=repo2(URL2) and that repository doesn't have the artifacts you acquired
>> from id=repo1(URL1).
>> 
>> The problem encountered for people flipping between using Central directly
>> and using a mirrorOf setting with a repository manager is as follows:
>> 
>> If you have no mirrorOf setting and you have POMs that contain repository
>> entries Maven will follow the repositories in the POMs and acquire any
>> dependencies from those repositories listed in the POMs. Now when you flip
>> to using a mirrorOf setting with a repository manager all those requests
>> will be routed through that single URL. If you have not setup the proxies
>> in your repository manager that correspond to the repositories in the POMs
>> the build will fail because those artifacts are not accessible to the
>> repository manager.
>> 
>> On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>> 
>>> Hi guys,
>>> 
>>> Not sure it is linked or not (i read the thread lately) but at work we
>> use
>>> a proxy and not at "home" and i often have to remove _maven.repo files
>>> (both ways) to make my build work again...that's an everyday pain.
>>> Le 3 févr. 2013 21:41, "Jason van Zyl" <ja...@tesla.io> a écrit :
>>> 
>>>> 
>>>> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
>>>> 
>>>>> +1.
>>>>> 
>>>>> Though the feature seems interesting, it should have had its own
>>>>> advertisement while being introduced.
>>>>> Even after re-reading
>>>>> 
>>>> 
>> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
>>>>> I'm
>>>>> still unsure about where/when it would bite me.
>>>> 
>>>> Does this make sense to you?
>>>> 
>>>> ---
>>>> 
>>>> h1. Enhanced Remote Repository Support
>>>> 
>>>> The feature verifies that the remote repositories configured for the
>>>> current build can be used to successfully resolve the artifact in
>> question.
>>>> If you retrieved an artifact in the past from Central and now changed
>> your
>>>> build to only know about Nexus and it doesn't have any knowledge of that
>>>> artifact then the build is going to fail. Put differently, if you purged
>>>> your local repo, your build won't work either. Neglecting offline mode,
>> the
>>>> goal is to ensure that the resolution works if it could be performed
>> using
>>>> a clean local repo with the current configuration. Giving confidence
>> that
>>>> co-workers can reproduce the build and not depend on some artifact
>>>> magically being pulled down into your local repository in the past
>> which is
>>>> nowhere to be found in the configured remote repository.
>>>> 
>>>> ---
>>>> 
>>>> And would you want that off by default?
>>>> 
>>>>> As I know and like Maven quite well, if I was bitten by that, I might
>> do
>>>>> some reseach and find jiras etc.
>>>>> 
>>>>> Others might just struggle to make it work and grow the maven bashing
>>>> group
>>>>> as Jeff said.
>>>>> 
>>>>> 
>>>>> 2013/2/1 Jeff MAURY <je...@jeffmaury.com>
>>>>> 
>>>>>> +1 on Arnaud's comments.
>>>>>> The main problem with this "feature" is that it is not documented
>> thus I
>>>>>> can't explain the real reason why Maven download several times
>> released
>>>>>> artifacts and this causes members of the Maven bashing group to grow
>>>>>> 
>>>>>> Jeff
>>>>>> 
>>>>>> 
>>>>>> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <ah...@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> My position was to propose the low cost possible solution to have a
>>>> quick
>>>>>>> fix and not to wait for months.
>>>>>>> If it could be fixed/configurable in aether it may be the solution to
>>>>>>> follow but I'm not sure about the status of this 3rd party project
>>>>>> (eclipse
>>>>>>> migration ...) on which we don't have the hand.
>>>>>>> Seriously I helped and lost MANY hours with this problem because it
>> is
>>>>>> hard
>>>>>>> to diagnose.
>>>>>>> I'm sure that many people abandoned to try to understand and just
>>>> dropped
>>>>>>> their local repo or decided to downgraded to m2 (or to switch to
>>>> another
>>>>>>> tool).
>>>>>>> I think we can have a lot of similar feedbacks.
>>>>>>> The worst thing is to have another thing that users don't understand
>>>>>> (lake
>>>>>>> of documentation ? communication ?)
>>>>>>> The side effect is that changing a repository id (or mirror id) makes
>>>>>> maven
>>>>>>> to re-download all the earth (while we are claiming from the
>> beginning
>>>>>> that
>>>>>>> Maven won't never download twice a release).
>>>>>>> And when the remote artifact just disappeared it is just a nightmare
>>>> due
>>>>>> to
>>>>>>> the lake of correct logs and this case is easy to have.
>>>>>>> For example in my company I have a profile to let people DL artifacts
>>>>>> from
>>>>>>> staging repositories (thus these are releases). It happened that they
>>>>>>> activated it once to test a build and then they rebuild the project
>>>>>> without
>>>>>>> the profile (thinking the artifact is in the local repo) and it fails
>>>> ...
>>>>>>> 
>>>>>>> Sincerely I think I had my worst headaches with maven due to this bug
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io>
>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hi Olivier,
>>>>>>>>> 
>>>>>>>>> Thx a lot for the fix. It will help a lot the community.
>>>>>>>>> But from my point of view it's perhaps not yet enough.
>>>>>>>>> We should :
>>>>>>>>> 1/ change the default behavior to deactivate this control which is
>>>>>>>>> difficult to understand
>>>>>>>> 
>>>>>>>> I disagree. We may want to change it slightly but it's only a
>> problem
>>>>>> for
>>>>>>>> people who flip between Maven a repository manager and without but
>>>> it's
>>>>>>> to
>>>>>>>> ensure the identity of a component. I haven't seen a huge number of
>>>>>>>> complaints. I do not want to turn this off. Improve it, sure, but
>>>>>> turning
>>>>>>>> it off by default I believe is not the right thing to do.
>>>>>>>> 
>>>>>>>>> 2/ change the error message when this control is activated to
>>>>>> clearly
>>>>>>>>> explain that the problem comes from the unavailability of the
>>>>>> artifact
>>>>>>> on
>>>>>>>>> its original remote repo.
>>>>>>>>> 
>>>>>>>>> For me 1/ is mandatory and 2/ a nice to have
>>>>>>>>> 
>>>>>>>>> WDYT ?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org>
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> I have pushed a fix for that.
>>>>>>>>>> Now you can desactivate the enhanced local repository using:
>>>>>>>>>> * new cli option: -slrm,--simple-local-repository-manager
>>>>>>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
>>>>>>>>>> 
>>>>>>>>>> will be available for testing here
>>>>>>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
>>>>>>>>>>> Hi Arnaud,
>>>>>>>>>>> 
>>>>>>>>>>>> +1 to consider the current behavior as a bug.
>>>>>>>>>>>> We should be able to deactivate it easily (and perhaps to have
>> it
>>>>>>> off
>>>>>>>> by
>>>>>>>>>>>> default to activate it only on CI servers)
>>>>>>>>>>> 
>>>>>>>>>>> :)
>>>>>>>>>>> 
>>>>>>>>>>>> and we should take care to have
>>>>>>>>>>>> a real error message explaining the issue and not a classical
>>>>>>>> dependency
>>>>>>>>>>>> not found while the artifact is in the local repo.
>>>>>>>>>>> 
>>>>>>>>>>> This is exactly filed here:
>>>>>>>>>>> http://jira.codehaus.org/browse/MNG-5185
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Arnaud
>>>>>>>>>>> Cheers
>>>>>>>>>>> Jörg
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> If know-how becomes know-where, then knowledge gets nowhere.
>>>>>>>>>>> [Jörg Hohwiller]
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Olivier Lamy
>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> -----
>>>>>>>>> Arnaud Héritier
>>>>>>>>> http://aheritier.net
>>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>>>> Twitter/Skype : aheritier
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Jason
>>>>>>>> 
>>>>>>>> ----------------------------------------------------------
>>>>>>>> Jason van Zyl
>>>>>>>> Founder & CTO, Sonatype
>>>>>>>> Founder,  Apache Maven
>>>>>>>> http://twitter.com/jvanzyl
>>>>>>>> ---------------------------------------------------------
>>>>>>>> 
>>>>>>>> Our achievements speak for themselves. What we have to keep track
>>>>>>>> of are our failures, discouragements and doubts. We tend to forget
>>>>>>>> the past difficulties, the many false starts, and the painful
>>>>>>>> groping. We see our past achievements as the end result of a
>>>>>>>> clean forward thrust, and our present difficulties as
>>>>>>>> signs of decline and decay.
>>>>>>>> 
>>>>>>>> -- Eric Hoffer, Reflections on the Human Condition
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> -----
>>>>>>> Arnaud Héritier
>>>>>>> http://aheritier.net
>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>> Twitter/Skype : aheritier
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Jeff MAURY
>>>>>> 
>>>>>> 
>>>>>> "Legacy code" often differs from its suggested alternative by actually
>>>>>> working and scaling.
>>>>>> - Bjarne Stroustrup
>>>>>> 
>>>>>> http://www.jeffmaury.com
>>>>>> http://riadiscuss.jeffmaury.com
>>>>>> http://www.twitter.com/jeffmaury
>>>>>> 
>>>>>> --
>>>>>> Baptiste <Batmat> MATHUS - http://batmat.net
>>>>>> Sauvez un arbre,
>>>>>> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>
>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder & CTO, Sonatype
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>> 
>>>> To do two things at once is to do neither.
>>>> 
>>>> -- Publilius Syrus, Roman slave, first century B.C.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> The modern conservative is engaged in one of man's oldest exercises in
>> moral philosophy; that is,
>> the search for a superior moral justification for selfishness.
>> 
>> -- John Kenneth Galbraith
>> 
>> 
>> 
>> 
>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. 

 -- Paul Graham

Re: Pain with MNG-5181 (_maven.repositories)

[Romain Manni-Bucau <rm...@gmail.com>]

I switch my settings and the only differences are:

1) some server config (i guess that's not important)
2) (more important) proxies (host/port)

i don't use mirrorOf.

PS: the issue can happen with tomee trunk so repos are always available
since the internet is available.

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/2/3 Jason van Zyl <ja...@tesla.io>

> If this is on one machine where you are not changing configurations or
> locations then something else is wrong as this does not happen for a
> machine that stays in the same place using the same settings.xml. Do you
> use a mirrorOf in your settings.xml that points to a group repository? Can
> you share your configuration? When you encounter this problem next, move
> your whole local repository out of the way (or use
> -Dmaven.repo.local=/tmp/repo) and you find that the build will fail.
>
> When this error occurs it means that the artifacts you're asking for are
> not available in any configured repository. You erase _maven.repositories
> file, and Maven does not verify that artifact's existence in the remote
> repository and let's you use the artifact you acquired locally by some
> other means.
>
> This generally happens as a result of switching between configurations
> which changes the id/url of the repository you are using. You do a build
> against id=repo1(URL1) and get some artifacts and those are recorded in the
> _maven.repositories files, and then you switch configurations and use
> id=repo2(URL2) and that repository doesn't have the artifacts you acquired
> from id=repo1(URL1).
>
> The problem encountered for people flipping between using Central directly
> and using a mirrorOf setting with a repository manager is as follows:
>
> If you have no mirrorOf setting and you have POMs that contain repository
> entries Maven will follow the repositories in the POMs and acquire any
> dependencies from those repositories listed in the POMs. Now when you flip
> to using a mirrorOf setting with a repository manager all those requests
> will be routed through that single URL. If you have not setup the proxies
> in your repository manager that correspond to the repositories in the POMs
> the build will fail because those artifacts are not accessible to the
> repository manager.
>
> On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Hi guys,
> >
> > Not sure it is linked or not (i read the thread lately) but at work we
> use
> > a proxy and not at "home" and i often have to remove _maven.repo files
> > (both ways) to make my build work again...that's an everyday pain.
> > Le 3 févr. 2013 21:41, "Jason van Zyl" <ja...@tesla.io> a écrit :
> >
> >>
> >> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
> >>
> >>> +1.
> >>>
> >>> Though the feature seems interesting, it should have had its own
> >>> advertisement while being introduced.
> >>> Even after re-reading
> >>>
> >>
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
> >>> I'm
> >>> still unsure about where/when it would bite me.
> >>
> >> Does this make sense to you?
> >>
> >> ---
> >>
> >> h1. Enhanced Remote Repository Support
> >>
> >> The feature verifies that the remote repositories configured for the
> >> current build can be used to successfully resolve the artifact in
> question.
> >> If you retrieved an artifact in the past from Central and now changed
> your
> >> build to only know about Nexus and it doesn't have any knowledge of that
> >> artifact then the build is going to fail. Put differently, if you purged
> >> your local repo, your build won't work either. Neglecting offline mode,
> the
> >> goal is to ensure that the resolution works if it could be performed
> using
> >> a clean local repo with the current configuration. Giving confidence
> that
> >> co-workers can reproduce the build and not depend on some artifact
> >> magically being pulled down into your local repository in the past
> which is
> >> nowhere to be found in the configured remote repository.
> >>
> >> ---
> >>
> >> And would you want that off by default?
> >>
> >>> As I know and like Maven quite well, if I was bitten by that, I might
> do
> >>> some reseach and find jiras etc.
> >>>
> >>> Others might just struggle to make it work and grow the maven bashing
> >> group
> >>> as Jeff said.
> >>>
> >>>
> >>> 2013/2/1 Jeff MAURY <je...@jeffmaury.com>
> >>>
> >>>> +1 on Arnaud's comments.
> >>>> The main problem with this "feature" is that it is not documented
> thus I
> >>>> can't explain the real reason why Maven download several times
> released
> >>>> artifacts and this causes members of the Maven bashing group to grow
> >>>>
> >>>> Jeff
> >>>>
> >>>>
> >>>> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <ah...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> My position was to propose the low cost possible solution to have a
> >> quick
> >>>>> fix and not to wait for months.
> >>>>> If it could be fixed/configurable in aether it may be the solution to
> >>>>> follow but I'm not sure about the status of this 3rd party project
> >>>> (eclipse
> >>>>> migration ...) on which we don't have the hand.
> >>>>> Seriously I helped and lost MANY hours with this problem because it
> is
> >>>> hard
> >>>>> to diagnose.
> >>>>> I'm sure that many people abandoned to try to understand and just
> >> dropped
> >>>>> their local repo or decided to downgraded to m2 (or to switch to
> >> another
> >>>>> tool).
> >>>>> I think we can have a lot of similar feedbacks.
> >>>>> The worst thing is to have another thing that users don't understand
> >>>> (lake
> >>>>> of documentation ? communication ?)
> >>>>> The side effect is that changing a repository id (or mirror id) makes
> >>>> maven
> >>>>> to re-download all the earth (while we are claiming from the
> beginning
> >>>> that
> >>>>> Maven won't never download twice a release).
> >>>>> And when the remote artifact just disappeared it is just a nightmare
> >> due
> >>>> to
> >>>>> the lake of correct logs and this case is easy to have.
> >>>>> For example in my company I have a profile to let people DL artifacts
> >>>> from
> >>>>> staging repositories (thus these are releases). It happened that they
> >>>>> activated it once to test a build and then they rebuild the project
> >>>> without
> >>>>> the profile (thinking the artifact is in the local repo) and it fails
> >> ...
> >>>>>
> >>>>> Sincerely I think I had my worst headaches with maven due to this bug
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io>
> wrote:
> >>>>>
> >>>>>>
> >>>>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Hi Olivier,
> >>>>>>>
> >>>>>>> Thx a lot for the fix. It will help a lot the community.
> >>>>>>> But from my point of view it's perhaps not yet enough.
> >>>>>>> We should :
> >>>>>>> 1/ change the default behavior to deactivate this control which is
> >>>>>>> difficult to understand
> >>>>>>
> >>>>>> I disagree. We may want to change it slightly but it's only a
> problem
> >>>> for
> >>>>>> people who flip between Maven a repository manager and without but
> >> it's
> >>>>> to
> >>>>>> ensure the identity of a component. I haven't seen a huge number of
> >>>>>> complaints. I do not want to turn this off. Improve it, sure, but
> >>>> turning
> >>>>>> it off by default I believe is not the right thing to do.
> >>>>>>
> >>>>>>> 2/ change the error message when this control is activated to
> >>>> clearly
> >>>>>>> explain that the problem comes from the unavailability of the
> >>>> artifact
> >>>>> on
> >>>>>>> its original remote repo.
> >>>>>>>
> >>>>>>> For me 1/ is mandatory and 2/ a nice to have
> >>>>>>>
> >>>>>>> WDYT ?
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> I have pushed a fix for that.
> >>>>>>>> Now you can desactivate the enhanced local repository using:
> >>>>>>>> * new cli option: -slrm,--simple-local-repository-manager
> >>>>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
> >>>>>>>>
> >>>>>>>> will be available for testing here
> >>>>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
> >>>>>>>>> Hi Arnaud,
> >>>>>>>>>
> >>>>>>>>>> +1 to consider the current behavior as a bug.
> >>>>>>>>>> We should be able to deactivate it easily (and perhaps to have
> it
> >>>>> off
> >>>>>> by
> >>>>>>>>>> default to activate it only on CI servers)
> >>>>>>>>>
> >>>>>>>>> :)
> >>>>>>>>>
> >>>>>>>>>> and we should take care to have
> >>>>>>>>>> a real error message explaining the issue and not a classical
> >>>>>> dependency
> >>>>>>>>>> not found while the artifact is in the local repo.
> >>>>>>>>>
> >>>>>>>>> This is exactly filed here:
> >>>>>>>>> http://jira.codehaus.org/browse/MNG-5185
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Arnaud
> >>>>>>>>> Cheers
> >>>>>>>>> Jörg
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> If know-how becomes know-where, then knowledge gets nowhere.
> >>>>>>>>> [Jörg Hohwiller]
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Olivier Lamy
> >>>>>>>> Talend: http://coders.talend.com
> >>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>>>>>>
> >>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> -----
> >>>>>>> Arnaud Héritier
> >>>>>>> http://aheritier.net
> >>>>>>> Mail/GTalk: aheritier AT gmail DOT com
> >>>>>>> Twitter/Skype : aheritier
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Jason
> >>>>>>
> >>>>>> ----------------------------------------------------------
> >>>>>> Jason van Zyl
> >>>>>> Founder & CTO, Sonatype
> >>>>>> Founder,  Apache Maven
> >>>>>> http://twitter.com/jvanzyl
> >>>>>> ---------------------------------------------------------
> >>>>>>
> >>>>>> Our achievements speak for themselves. What we have to keep track
> >>>>>> of are our failures, discouragements and doubts. We tend to forget
> >>>>>> the past difficulties, the many false starts, and the painful
> >>>>>> groping. We see our past achievements as the end result of a
> >>>>>> clean forward thrust, and our present difficulties as
> >>>>>> signs of decline and decay.
> >>>>>>
> >>>>>> -- Eric Hoffer, Reflections on the Human Condition
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> -----
> >>>>> Arnaud Héritier
> >>>>> http://aheritier.net
> >>>>> Mail/GTalk: aheritier AT gmail DOT com
> >>>>> Twitter/Skype : aheritier
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Jeff MAURY
> >>>>
> >>>>
> >>>> "Legacy code" often differs from its suggested alternative by actually
> >>>> working and scaling.
> >>>> - Bjarne Stroustrup
> >>>>
> >>>> http://www.jeffmaury.com
> >>>> http://riadiscuss.jeffmaury.com
> >>>> http://www.twitter.com/jeffmaury
> >>>>
> >>>> --
> >>>> Baptiste <Batmat> MATHUS - http://batmat.net
> >>>> Sauvez un arbre,
> >>>> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder & CTO, Sonatype
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >>
> >> To do two things at once is to do neither.
> >>
> >> -- Publilius Syrus, Roman slave, first century B.C.
> >>
> >>
> >>
> >>
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> The modern conservative is engaged in one of man's oldest exercises in
> moral philosophy; that is,
> the search for a superior moral justification for selfishness.
>
>  -- John Kenneth Galbraith
>
>
>
>
>
>

Re: Pain with MNG-5181 (_maven.repositories)

[Jason van Zyl <ja...@tesla.io>]

If this is on one machine where you are not changing configurations or locations then something else is wrong as this does not happen for a machine that stays in the same place using the same settings.xml. Do you use a mirrorOf in your settings.xml that points to a group repository? Can you share your configuration? When you encounter this problem next, move your whole local repository out of the way (or use -Dmaven.repo.local=/tmp/repo) and you find that the build will fail.

When this error occurs it means that the artifacts you're asking for are not available in any configured repository. You erase _maven.repositories file, and Maven does not verify that artifact's existence in the remote repository and let's you use the artifact you acquired locally by some other means. 

This generally happens as a result of switching between configurations which changes the id/url of the repository you are using. You do a build against id=repo1(URL1) and get some artifacts and those are recorded in the _maven.repositories files, and then you switch configurations and use id=repo2(URL2) and that repository doesn't have the artifacts you acquired from id=repo1(URL1).

The problem encountered for people flipping between using Central directly and using a mirrorOf setting with a repository manager is as follows:

If you have no mirrorOf setting and you have POMs that contain repository entries Maven will follow the repositories in the POMs and acquire any dependencies from those repositories listed in the POMs. Now when you flip to using a mirrorOf setting with a repository manager all those requests will be routed through that single URL. If you have not setup the proxies in your repository manager that correspond to the repositories in the POMs the build will fail because those artifacts are not accessible to the repository manager. 

On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:

> Hi guys,
> 
> Not sure it is linked or not (i read the thread lately) but at work we use
> a proxy and not at "home" and i often have to remove _maven.repo files
> (both ways) to make my build work again...that's an everyday pain.
> Le 3 févr. 2013 21:41, "Jason van Zyl" <ja...@tesla.io> a écrit :
> 
>> 
>> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
>> 
>>> +1.
>>> 
>>> Though the feature seems interesting, it should have had its own
>>> advertisement while being introduced.
>>> Even after re-reading
>>> 
>> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
>>> I'm
>>> still unsure about where/when it would bite me.
>> 
>> Does this make sense to you?
>> 
>> ---
>> 
>> h1. Enhanced Remote Repository Support
>> 
>> The feature verifies that the remote repositories configured for the
>> current build can be used to successfully resolve the artifact in question.
>> If you retrieved an artifact in the past from Central and now changed your
>> build to only know about Nexus and it doesn't have any knowledge of that
>> artifact then the build is going to fail. Put differently, if you purged
>> your local repo, your build won't work either. Neglecting offline mode, the
>> goal is to ensure that the resolution works if it could be performed using
>> a clean local repo with the current configuration. Giving confidence that
>> co-workers can reproduce the build and not depend on some artifact
>> magically being pulled down into your local repository in the past which is
>> nowhere to be found in the configured remote repository.
>> 
>> ---
>> 
>> And would you want that off by default?
>> 
>>> As I know and like Maven quite well, if I was bitten by that, I might do
>>> some reseach and find jiras etc.
>>> 
>>> Others might just struggle to make it work and grow the maven bashing
>> group
>>> as Jeff said.
>>> 
>>> 
>>> 2013/2/1 Jeff MAURY <je...@jeffmaury.com>
>>> 
>>>> +1 on Arnaud's comments.
>>>> The main problem with this "feature" is that it is not documented thus I
>>>> can't explain the real reason why Maven download several times released
>>>> artifacts and this causes members of the Maven bashing group to grow
>>>> 
>>>> Jeff
>>>> 
>>>> 
>>>> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <ah...@gmail.com>
>>>> wrote:
>>>> 
>>>>> My position was to propose the low cost possible solution to have a
>> quick
>>>>> fix and not to wait for months.
>>>>> If it could be fixed/configurable in aether it may be the solution to
>>>>> follow but I'm not sure about the status of this 3rd party project
>>>> (eclipse
>>>>> migration ...) on which we don't have the hand.
>>>>> Seriously I helped and lost MANY hours with this problem because it is
>>>> hard
>>>>> to diagnose.
>>>>> I'm sure that many people abandoned to try to understand and just
>> dropped
>>>>> their local repo or decided to downgraded to m2 (or to switch to
>> another
>>>>> tool).
>>>>> I think we can have a lot of similar feedbacks.
>>>>> The worst thing is to have another thing that users don't understand
>>>> (lake
>>>>> of documentation ? communication ?)
>>>>> The side effect is that changing a repository id (or mirror id) makes
>>>> maven
>>>>> to re-download all the earth (while we are claiming from the beginning
>>>> that
>>>>> Maven won't never download twice a release).
>>>>> And when the remote artifact just disappeared it is just a nightmare
>> due
>>>> to
>>>>> the lake of correct logs and this case is easy to have.
>>>>> For example in my company I have a profile to let people DL artifacts
>>>> from
>>>>> staging repositories (thus these are releases). It happened that they
>>>>> activated it once to test a build and then they rebuild the project
>>>> without
>>>>> the profile (thinking the artifact is in the local repo) and it fails
>> ...
>>>>> 
>>>>> Sincerely I think I had my worst headaches with maven due to this bug
>>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io> wrote:
>>>>> 
>>>>>> 
>>>>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>>> Hi Olivier,
>>>>>>> 
>>>>>>> Thx a lot for the fix. It will help a lot the community.
>>>>>>> But from my point of view it's perhaps not yet enough.
>>>>>>> We should :
>>>>>>> 1/ change the default behavior to deactivate this control which is
>>>>>>> difficult to understand
>>>>>> 
>>>>>> I disagree. We may want to change it slightly but it's only a problem
>>>> for
>>>>>> people who flip between Maven a repository manager and without but
>> it's
>>>>> to
>>>>>> ensure the identity of a component. I haven't seen a huge number of
>>>>>> complaints. I do not want to turn this off. Improve it, sure, but
>>>> turning
>>>>>> it off by default I believe is not the right thing to do.
>>>>>> 
>>>>>>> 2/ change the error message when this control is activated to
>>>> clearly
>>>>>>> explain that the problem comes from the unavailability of the
>>>> artifact
>>>>> on
>>>>>>> its original remote repo.
>>>>>>> 
>>>>>>> For me 1/ is mandatory and 2/ a nice to have
>>>>>>> 
>>>>>>> WDYT ?
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org>
>>>>> wrote:
>>>>>>> 
>>>>>>>> I have pushed a fix for that.
>>>>>>>> Now you can desactivate the enhanced local repository using:
>>>>>>>> * new cli option: -slrm,--simple-local-repository-manager
>>>>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
>>>>>>>> 
>>>>>>>> will be available for testing here
>>>>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
>>>>>>>>> Hi Arnaud,
>>>>>>>>> 
>>>>>>>>>> +1 to consider the current behavior as a bug.
>>>>>>>>>> We should be able to deactivate it easily (and perhaps to have it
>>>>> off
>>>>>> by
>>>>>>>>>> default to activate it only on CI servers)
>>>>>>>>> 
>>>>>>>>> :)
>>>>>>>>> 
>>>>>>>>>> and we should take care to have
>>>>>>>>>> a real error message explaining the issue and not a classical
>>>>>> dependency
>>>>>>>>>> not found while the artifact is in the local repo.
>>>>>>>>> 
>>>>>>>>> This is exactly filed here:
>>>>>>>>> http://jira.codehaus.org/browse/MNG-5185
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Arnaud
>>>>>>>>> Cheers
>>>>>>>>> Jörg
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> If know-how becomes know-where, then knowledge gets nowhere.
>>>>>>>>> [Jörg Hohwiller]
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Olivier Lamy
>>>>>>>> Talend: http://coders.talend.com
>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>> 
>>>>>>>> 
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> -----
>>>>>>> Arnaud Héritier
>>>>>>> http://aheritier.net
>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>> Twitter/Skype : aheritier
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Jason
>>>>>> 
>>>>>> ----------------------------------------------------------
>>>>>> Jason van Zyl
>>>>>> Founder & CTO, Sonatype
>>>>>> Founder,  Apache Maven
>>>>>> http://twitter.com/jvanzyl
>>>>>> ---------------------------------------------------------
>>>>>> 
>>>>>> Our achievements speak for themselves. What we have to keep track
>>>>>> of are our failures, discouragements and doubts. We tend to forget
>>>>>> the past difficulties, the many false starts, and the painful
>>>>>> groping. We see our past achievements as the end result of a
>>>>>> clean forward thrust, and our present difficulties as
>>>>>> signs of decline and decay.
>>>>>> 
>>>>>> -- Eric Hoffer, Reflections on the Human Condition
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> -----
>>>>> Arnaud Héritier
>>>>> http://aheritier.net
>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>> Twitter/Skype : aheritier
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Jeff MAURY
>>>> 
>>>> 
>>>> "Legacy code" often differs from its suggested alternative by actually
>>>> working and scaling.
>>>> - Bjarne Stroustrup
>>>> 
>>>> http://www.jeffmaury.com
>>>> http://riadiscuss.jeffmaury.com
>>>> http://www.twitter.com/jeffmaury
>>>> 
>>>> --
>>>> Baptiste <Batmat> MATHUS - http://batmat.net
>>>> Sauvez un arbre,
>>>> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> To do two things at once is to do neither.
>> 
>> -- Publilius Syrus, Roman slave, first century B.C.
>> 
>> 
>> 
>> 
>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, 
the search for a superior moral justification for selfishness.

 -- John Kenneth Galbraith

Re: Pain with MNG-5181 (_maven.repositories)

[Romain Manni-Bucau <rm...@gmail.com>]

Hi guys,

Not sure it is linked or not (i read the thread lately) but at work we use
a proxy and not at "home" and i often have to remove _maven.repo files
(both ways) to make my build work again...that's an everyday pain.
Le 3 févr. 2013 21:41, "Jason van Zyl" <ja...@tesla.io> a écrit :

>
> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
>
> > +1.
> >
> > Though the feature seems interesting, it should have had its own
> > advertisement while being introduced.
> > Even after re-reading
> >
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
> > I'm
> > still unsure about where/when it would bite me.
>
> Does this make sense to you?
>
> ---
>
> h1. Enhanced Remote Repository Support
>
> The feature verifies that the remote repositories configured for the
> current build can be used to successfully resolve the artifact in question.
> If you retrieved an artifact in the past from Central and now changed your
> build to only know about Nexus and it doesn't have any knowledge of that
> artifact then the build is going to fail. Put differently, if you purged
> your local repo, your build won't work either. Neglecting offline mode, the
> goal is to ensure that the resolution works if it could be performed using
> a clean local repo with the current configuration. Giving confidence that
> co-workers can reproduce the build and not depend on some artifact
> magically being pulled down into your local repository in the past which is
> nowhere to be found in the configured remote repository.
>
> ---
>
> And would you want that off by default?
>
> > As I know and like Maven quite well, if I was bitten by that, I might do
> > some reseach and find jiras etc.
> >
> > Others might just struggle to make it work and grow the maven bashing
> group
> > as Jeff said.
> >
> >
> > 2013/2/1 Jeff MAURY <je...@jeffmaury.com>
> >
> >> +1 on Arnaud's comments.
> >> The main problem with this "feature" is that it is not documented thus I
> >> can't explain the real reason why Maven download several times released
> >> artifacts and this causes members of the Maven bashing group to grow
> >>
> >> Jeff
> >>
> >>
> >> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <ah...@gmail.com>
> >> wrote:
> >>
> >>> My position was to propose the low cost possible solution to have a
> quick
> >>> fix and not to wait for months.
> >>> If it could be fixed/configurable in aether it may be the solution to
> >>> follow but I'm not sure about the status of this 3rd party project
> >> (eclipse
> >>> migration ...) on which we don't have the hand.
> >>> Seriously I helped and lost MANY hours with this problem because it is
> >> hard
> >>> to diagnose.
> >>> I'm sure that many people abandoned to try to understand and just
> dropped
> >>> their local repo or decided to downgraded to m2 (or to switch to
> another
> >>> tool).
> >>> I think we can have a lot of similar feedbacks.
> >>> The worst thing is to have another thing that users don't understand
> >> (lake
> >>> of documentation ? communication ?)
> >>> The side effect is that changing a repository id (or mirror id) makes
> >> maven
> >>> to re-download all the earth (while we are claiming from the beginning
> >> that
> >>> Maven won't never download twice a release).
> >>> And when the remote artifact just disappeared it is just a nightmare
> due
> >> to
> >>> the lake of correct logs and this case is easy to have.
> >>> For example in my company I have a profile to let people DL artifacts
> >> from
> >>> staging repositories (thus these are releases). It happened that they
> >>> activated it once to test a build and then they rebuild the project
> >> without
> >>> the profile (thinking the artifact is in the local repo) and it fails
> ...
> >>>
> >>> Sincerely I think I had my worst headaches with maven due to this bug
> >>>
> >>>
> >>>
> >>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io> wrote:
> >>>
> >>>>
> >>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com>
> >>> wrote:
> >>>>
> >>>>> Hi Olivier,
> >>>>>
> >>>>> Thx a lot for the fix. It will help a lot the community.
> >>>>> But from my point of view it's perhaps not yet enough.
> >>>>> We should :
> >>>>> 1/ change the default behavior to deactivate this control which is
> >>>>> difficult to understand
> >>>>
> >>>> I disagree. We may want to change it slightly but it's only a problem
> >> for
> >>>> people who flip between Maven a repository manager and without but
> it's
> >>> to
> >>>> ensure the identity of a component. I haven't seen a huge number of
> >>>> complaints. I do not want to turn this off. Improve it, sure, but
> >> turning
> >>>> it off by default I believe is not the right thing to do.
> >>>>
> >>>>> 2/ change the error message when this control is activated to
> >> clearly
> >>>>> explain that the problem comes from the unavailability of the
> >> artifact
> >>> on
> >>>>> its original remote repo.
> >>>>>
> >>>>> For me 1/ is mandatory and 2/ a nice to have
> >>>>>
> >>>>> WDYT ?
> >>>>>
> >>>>>
> >>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org>
> >>> wrote:
> >>>>>
> >>>>>> I have pushed a fix for that.
> >>>>>> Now you can desactivate the enhanced local repository using:
> >>>>>> * new cli option: -slrm,--simple-local-repository-manager
> >>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
> >>>>>>
> >>>>>> will be available for testing here
> >>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
> >>>>>>
> >>>>>>
> >>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
> >>>>>>> Hi Arnaud,
> >>>>>>>
> >>>>>>>> +1 to consider the current behavior as a bug.
> >>>>>>>> We should be able to deactivate it easily (and perhaps to have it
> >>> off
> >>>> by
> >>>>>>>> default to activate it only on CI servers)
> >>>>>>>
> >>>>>>> :)
> >>>>>>>
> >>>>>>>> and we should take care to have
> >>>>>>>> a real error message explaining the issue and not a classical
> >>>> dependency
> >>>>>>>> not found while the artifact is in the local repo.
> >>>>>>>
> >>>>>>> This is exactly filed here:
> >>>>>>> http://jira.codehaus.org/browse/MNG-5185
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Arnaud
> >>>>>>> Cheers
> >>>>>>> Jörg
> >>>>>>>
> >>>>>>> --
> >>>>>>> If know-how becomes know-where, then knowledge gets nowhere.
> >>>>>>> [Jörg Hohwiller]
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Olivier Lamy
> >>>>>> Talend: http://coders.talend.com
> >>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>>>>
> >>>>>>
> >> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> -----
> >>>>> Arnaud Héritier
> >>>>> http://aheritier.net
> >>>>> Mail/GTalk: aheritier AT gmail DOT com
> >>>>> Twitter/Skype : aheritier
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jason
> >>>>
> >>>> ----------------------------------------------------------
> >>>> Jason van Zyl
> >>>> Founder & CTO, Sonatype
> >>>> Founder,  Apache Maven
> >>>> http://twitter.com/jvanzyl
> >>>> ---------------------------------------------------------
> >>>>
> >>>> Our achievements speak for themselves. What we have to keep track
> >>>> of are our failures, discouragements and doubts. We tend to forget
> >>>> the past difficulties, the many false starts, and the painful
> >>>> groping. We see our past achievements as the end result of a
> >>>> clean forward thrust, and our present difficulties as
> >>>> signs of decline and decay.
> >>>>
> >>>> -- Eric Hoffer, Reflections on the Human Condition
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> -----
> >>> Arnaud Héritier
> >>> http://aheritier.net
> >>> Mail/GTalk: aheritier AT gmail DOT com
> >>> Twitter/Skype : aheritier
> >>>
> >>
> >>
> >>
> >> --
> >> Jeff MAURY
> >>
> >>
> >> "Legacy code" often differs from its suggested alternative by actually
> >> working and scaling.
> >> - Bjarne Stroustrup
> >>
> >> http://www.jeffmaury.com
> >> http://riadiscuss.jeffmaury.com
> >> http://www.twitter.com/jeffmaury
> >>
> >> --
> >> Baptiste <Batmat> MATHUS - http://batmat.net
> >> Sauvez un arbre,
> >> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> To do two things at once is to do neither.
>
>  -- Publilius Syrus, Roman slave, first century B.C.
>
>
>
>
>
>

Re: Pain with MNG-5181 (_maven.repositories)

[Jason van Zyl <ja...@tesla.io>]

On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml...@batmat.net> wrote:

> +1.
> 
> Though the feature seems interesting, it should have had its own
> advertisement while being introduced.
> Even after re-reading
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
> I'm
> still unsure about where/when it would bite me.

Does this make sense to you?

---

h1. Enhanced Remote Repository Support

The feature verifies that the remote repositories configured for the current build can be used to successfully resolve the artifact in question. If you retrieved an artifact in the past from Central and now changed your build to only know about Nexus and it doesn't have any knowledge of that artifact then the build is going to fail. Put differently, if you purged your local repo, your build won't work either. Neglecting offline mode, the goal is to ensure that the resolution works if it could be performed using a clean local repo with the current configuration. Giving confidence that co-workers can reproduce the build and not depend on some artifact magically being pulled down into your local repository in the past which is nowhere to be found in the configured remote repository.

---

And would you want that off by default?

> As I know and like Maven quite well, if I was bitten by that, I might do
> some reseach and find jiras etc.
> 
> Others might just struggle to make it work and grow the maven bashing group
> as Jeff said.
> 
> 
> 2013/2/1 Jeff MAURY <je...@jeffmaury.com>
> 
>> +1 on Arnaud's comments.
>> The main problem with this "feature" is that it is not documented thus I
>> can't explain the real reason why Maven download several times released
>> artifacts and this causes members of the Maven bashing group to grow
>> 
>> Jeff
>> 
>> 
>> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <ah...@gmail.com>
>> wrote:
>> 
>>> My position was to propose the low cost possible solution to have a quick
>>> fix and not to wait for months.
>>> If it could be fixed/configurable in aether it may be the solution to
>>> follow but I'm not sure about the status of this 3rd party project
>> (eclipse
>>> migration ...) on which we don't have the hand.
>>> Seriously I helped and lost MANY hours with this problem because it is
>> hard
>>> to diagnose.
>>> I'm sure that many people abandoned to try to understand and just dropped
>>> their local repo or decided to downgraded to m2 (or to switch to another
>>> tool).
>>> I think we can have a lot of similar feedbacks.
>>> The worst thing is to have another thing that users don't understand
>> (lake
>>> of documentation ? communication ?)
>>> The side effect is that changing a repository id (or mirror id) makes
>> maven
>>> to re-download all the earth (while we are claiming from the beginning
>> that
>>> Maven won't never download twice a release).
>>> And when the remote artifact just disappeared it is just a nightmare due
>> to
>>> the lake of correct logs and this case is easy to have.
>>> For example in my company I have a profile to let people DL artifacts
>> from
>>> staging repositories (thus these are releases). It happened that they
>>> activated it once to test a build and then they rebuild the project
>> without
>>> the profile (thinking the artifact is in the local repo) and it fails ...
>>> 
>>> Sincerely I think I had my worst headaches with maven due to this bug
>>> 
>>> 
>>> 
>>> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io> wrote:
>>> 
>>>> 
>>>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com>
>>> wrote:
>>>> 
>>>>> Hi Olivier,
>>>>> 
>>>>> Thx a lot for the fix. It will help a lot the community.
>>>>> But from my point of view it's perhaps not yet enough.
>>>>> We should :
>>>>> 1/ change the default behavior to deactivate this control which is
>>>>> difficult to understand
>>>> 
>>>> I disagree. We may want to change it slightly but it's only a problem
>> for
>>>> people who flip between Maven a repository manager and without but it's
>>> to
>>>> ensure the identity of a component. I haven't seen a huge number of
>>>> complaints. I do not want to turn this off. Improve it, sure, but
>> turning
>>>> it off by default I believe is not the right thing to do.
>>>> 
>>>>> 2/ change the error message when this control is activated to
>> clearly
>>>>> explain that the problem comes from the unavailability of the
>> artifact
>>> on
>>>>> its original remote repo.
>>>>> 
>>>>> For me 1/ is mandatory and 2/ a nice to have
>>>>> 
>>>>> WDYT ?
>>>>> 
>>>>> 
>>>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org>
>>> wrote:
>>>>> 
>>>>>> I have pushed a fix for that.
>>>>>> Now you can desactivate the enhanced local repository using:
>>>>>> * new cli option: -slrm,--simple-local-repository-manager
>>>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
>>>>>> 
>>>>>> will be available for testing here
>>>>>> https://builds.apache.org/job/maven-3.x/ with build #368
>>>>>> 
>>>>>> 
>>>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
>>>>>>> Hi Arnaud,
>>>>>>> 
>>>>>>>> +1 to consider the current behavior as a bug.
>>>>>>>> We should be able to deactivate it easily (and perhaps to have it
>>> off
>>>> by
>>>>>>>> default to activate it only on CI servers)
>>>>>>> 
>>>>>>> :)
>>>>>>> 
>>>>>>>> and we should take care to have
>>>>>>>> a real error message explaining the issue and not a classical
>>>> dependency
>>>>>>>> not found while the artifact is in the local repo.
>>>>>>> 
>>>>>>> This is exactly filed here:
>>>>>>> http://jira.codehaus.org/browse/MNG-5185
>>>>>>> 
>>>>>>>> 
>>>>>>>> Arnaud
>>>>>>> Cheers
>>>>>>> Jörg
>>>>>>> 
>>>>>>> --
>>>>>>> If know-how becomes know-where, then knowledge gets nowhere.
>>>>>>> [Jörg Hohwiller]
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Olivier Lamy
>>>>>> Talend: http://coders.talend.com
>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>> 
>>>>>> 
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> -----
>>>>> Arnaud Héritier
>>>>> http://aheritier.net
>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>> Twitter/Skype : aheritier
>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder & CTO, Sonatype
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>> 
>>>> Our achievements speak for themselves. What we have to keep track
>>>> of are our failures, discouragements and doubts. We tend to forget
>>>> the past difficulties, the many false starts, and the painful
>>>> groping. We see our past achievements as the end result of a
>>>> clean forward thrust, and our present difficulties as
>>>> signs of decline and decay.
>>>> 
>>>> -- Eric Hoffer, Reflections on the Human Condition
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> -----
>>> Arnaud Héritier
>>> http://aheritier.net
>>> Mail/GTalk: aheritier AT gmail DOT com
>>> Twitter/Skype : aheritier
>>> 
>> 
>> 
>> 
>> --
>> Jeff MAURY
>> 
>> 
>> "Legacy code" often differs from its suggested alternative by actually
>> working and scaling.
>> - Bjarne Stroustrup
>> 
>> http://www.jeffmaury.com
>> http://riadiscuss.jeffmaury.com
>> http://www.twitter.com/jeffmaury
>> 
>> --
>> Baptiste <Batmat> MATHUS - http://batmat.net
>> Sauvez un arbre,
>> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

To do two things at once is to do neither.
 
 -- Publilius Syrus, Roman slave, first century B.C.

Re: Pain with MNG-5181 (_maven.repositories)

[Baptiste MATHUS <ml...@batmat.net>]

+1.

Though the feature seems interesting, it should have had its own
advertisement while being introduced.
Even after re-reading
https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
I'm
still unsure about where/when it would bite me.
As I know and like Maven quite well, if I was bitten by that, I might do
some reseach and find jiras etc.

Others might just struggle to make it work and grow the maven bashing group
as Jeff said.


2013/2/1 Jeff MAURY <je...@jeffmaury.com>

> +1 on Arnaud's comments.
> The main problem with this "feature" is that it is not documented thus I
> can't explain the real reason why Maven download several times released
> artifacts and this causes members of the Maven bashing group to grow
>
> Jeff
>
>
> On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <ah...@gmail.com>
> wrote:
>
> > My position was to propose the low cost possible solution to have a quick
> > fix and not to wait for months.
> > If it could be fixed/configurable in aether it may be the solution to
> > follow but I'm not sure about the status of this 3rd party project
> (eclipse
> > migration ...) on which we don't have the hand.
> > Seriously I helped and lost MANY hours with this problem because it is
> hard
> > to diagnose.
> > I'm sure that many people abandoned to try to understand and just dropped
> > their local repo or decided to downgraded to m2 (or to switch to another
> > tool).
> > I think we can have a lot of similar feedbacks.
> > The worst thing is to have another thing that users don't understand
> (lake
> > of documentation ? communication ?)
> > The side effect is that changing a repository id (or mirror id) makes
> maven
> > to re-download all the earth (while we are claiming from the beginning
> that
> > Maven won't never download twice a release).
> > And when the remote artifact just disappeared it is just a nightmare due
> to
> > the lake of correct logs and this case is easy to have.
> > For example in my company I have a profile to let people DL artifacts
> from
> > staging repositories (thus these are releases). It happened that they
> > activated it once to test a build and then they rebuild the project
> without
> > the profile (thinking the artifact is in the local repo) and it fails ...
> >
> > Sincerely I think I had my worst headaches with maven due to this bug
> >
> >
> >
> > On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io> wrote:
> >
> > >
> > > On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com>
> > wrote:
> > >
> > > > Hi Olivier,
> > > >
> > > >  Thx a lot for the fix. It will help a lot the community.
> > > >  But from my point of view it's perhaps not yet enough.
> > > >  We should :
> > > >  1/ change the default behavior to deactivate this control which is
> > > > difficult to understand
> > >
> > > I disagree. We may want to change it slightly but it's only a problem
> for
> > > people who flip between Maven a repository manager and without but it's
> > to
> > > ensure the identity of a component. I haven't seen a huge number of
> > > complaints. I do not want to turn this off. Improve it, sure, but
> turning
> > > it off by default I believe is not the right thing to do.
> > >
> > > >  2/ change the error message when this control is activated to
> clearly
> > > > explain that the problem comes from the unavailability of the
> artifact
> > on
> > > > its original remote repo.
> > > >
> > > >  For me 1/ is mandatory and 2/ a nice to have
> > > >
> > > > WDYT ?
> > > >
> > > >
> > > > On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org>
> > wrote:
> > > >
> > > >> I have pushed a fix for that.
> > > >> Now you can desactivate the enhanced local repository using:
> > > >> * new cli option: -slrm,--simple-local-repository-manager
> > > >> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
> > > >>
> > > >> will be available for testing here
> > > >> https://builds.apache.org/job/maven-3.x/ with build #368
> > > >>
> > > >>
> > > >> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
> > > >>> Hi Arnaud,
> > > >>>
> > > >>>> +1 to consider the current behavior as a bug.
> > > >>>> We should be able to deactivate it easily (and perhaps to have it
> > off
> > > by
> > > >>>> default to activate it only on CI servers)
> > > >>>
> > > >>> :)
> > > >>>
> > > >>>> and we should take care to have
> > > >>>> a real error message explaining the issue and not a classical
> > > dependency
> > > >>>> not found while the artifact is in the local repo.
> > > >>>
> > > >>> This is exactly filed here:
> > > >>> http://jira.codehaus.org/browse/MNG-5185
> > > >>>
> > > >>>>
> > > >>>> Arnaud
> > > >>> Cheers
> > > >>>  Jörg
> > > >>>
> > > >>> --
> > > >>> If know-how becomes know-where, then knowledge gets nowhere.
> > > >>>  [Jörg Hohwiller]
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Olivier Lamy
> > > >> Talend: http://coders.talend.com
> > > >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > -----
> > > > Arnaud Héritier
> > > > http://aheritier.net
> > > > Mail/GTalk: aheritier AT gmail DOT com
> > > > Twitter/Skype : aheritier
> > >
> > > Thanks,
> > >
> > > Jason
> > >
> > > ----------------------------------------------------------
> > > Jason van Zyl
> > > Founder & CTO, Sonatype
> > > Founder,  Apache Maven
> > > http://twitter.com/jvanzyl
> > > ---------------------------------------------------------
> > >
> > > Our achievements speak for themselves. What we have to keep track
> > > of are our failures, discouragements and doubts. We tend to forget
> > > the past difficulties, the many false starts, and the painful
> > > groping. We see our past achievements as the end result of a
> > > clean forward thrust, and our present difficulties as
> > > signs of decline and decay.
> > >
> > >  -- Eric Hoffer, Reflections on the Human Condition
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > -----
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
> >
>
>
>
> --
> Jeff MAURY
>
>
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
>  - Bjarne Stroustrup
>
> http://www.jeffmaury.com
> http://riadiscuss.jeffmaury.com
> http://www.twitter.com/jeffmaury
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! <http://www.twitter.com/jeffmaury>

Re: Pain with MNG-5181 (_maven.repositories)

[Jeff MAURY <je...@jeffmaury.com>]

+1 on Arnaud's comments.
The main problem with this "feature" is that it is not documented thus I
can't explain the real reason why Maven download several times released
artifacts and this causes members of the Maven bashing group to grow

Jeff


On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <ah...@gmail.com> wrote:

> My position was to propose the low cost possible solution to have a quick
> fix and not to wait for months.
> If it could be fixed/configurable in aether it may be the solution to
> follow but I'm not sure about the status of this 3rd party project (eclipse
> migration ...) on which we don't have the hand.
> Seriously I helped and lost MANY hours with this problem because it is hard
> to diagnose.
> I'm sure that many people abandoned to try to understand and just dropped
> their local repo or decided to downgraded to m2 (or to switch to another
> tool).
> I think we can have a lot of similar feedbacks.
> The worst thing is to have another thing that users don't understand (lake
> of documentation ? communication ?)
> The side effect is that changing a repository id (or mirror id) makes maven
> to re-download all the earth (while we are claiming from the beginning that
> Maven won't never download twice a release).
> And when the remote artifact just disappeared it is just a nightmare due to
> the lake of correct logs and this case is easy to have.
> For example in my company I have a profile to let people DL artifacts from
> staging repositories (thus these are releases). It happened that they
> activated it once to test a build and then they rebuild the project without
> the profile (thinking the artifact is in the local repo) and it fails ...
>
> Sincerely I think I had my worst headaches with maven due to this bug
>
>
>
> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io> wrote:
>
> >
> > On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com>
> wrote:
> >
> > > Hi Olivier,
> > >
> > >  Thx a lot for the fix. It will help a lot the community.
> > >  But from my point of view it's perhaps not yet enough.
> > >  We should :
> > >  1/ change the default behavior to deactivate this control which is
> > > difficult to understand
> >
> > I disagree. We may want to change it slightly but it's only a problem for
> > people who flip between Maven a repository manager and without but it's
> to
> > ensure the identity of a component. I haven't seen a huge number of
> > complaints. I do not want to turn this off. Improve it, sure, but turning
> > it off by default I believe is not the right thing to do.
> >
> > >  2/ change the error message when this control is activated to clearly
> > > explain that the problem comes from the unavailability of the artifact
> on
> > > its original remote repo.
> > >
> > >  For me 1/ is mandatory and 2/ a nice to have
> > >
> > > WDYT ?
> > >
> > >
> > > On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org>
> wrote:
> > >
> > >> I have pushed a fix for that.
> > >> Now you can desactivate the enhanced local repository using:
> > >> * new cli option: -slrm,--simple-local-repository-manager
> > >> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
> > >>
> > >> will be available for testing here
> > >> https://builds.apache.org/job/maven-3.x/ with build #368
> > >>
> > >>
> > >> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
> > >>> Hi Arnaud,
> > >>>
> > >>>> +1 to consider the current behavior as a bug.
> > >>>> We should be able to deactivate it easily (and perhaps to have it
> off
> > by
> > >>>> default to activate it only on CI servers)
> > >>>
> > >>> :)
> > >>>
> > >>>> and we should take care to have
> > >>>> a real error message explaining the issue and not a classical
> > dependency
> > >>>> not found while the artifact is in the local repo.
> > >>>
> > >>> This is exactly filed here:
> > >>> http://jira.codehaus.org/browse/MNG-5185
> > >>>
> > >>>>
> > >>>> Arnaud
> > >>> Cheers
> > >>>  Jörg
> > >>>
> > >>> --
> > >>> If know-how becomes know-where, then knowledge gets nowhere.
> > >>>  [Jörg Hohwiller]
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Olivier Lamy
> > >> Talend: http://coders.talend.com
> > >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > -----
> > > Arnaud Héritier
> > > http://aheritier.net
> > > Mail/GTalk: aheritier AT gmail DOT com
> > > Twitter/Skype : aheritier
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder & CTO, Sonatype
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> > Our achievements speak for themselves. What we have to keep track
> > of are our failures, discouragements and doubts. We tend to forget
> > the past difficulties, the many false starts, and the painful
> > groping. We see our past achievements as the end result of a
> > clean forward thrust, and our present difficulties as
> > signs of decline and decay.
> >
> >  -- Eric Hoffer, Reflections on the Human Condition
> >
> >
> >
> >
> >
> >
>
>
> --
> -----
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>



-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury

Re: Pain with MNG-5181 (_maven.repositories)

[Jason van Zyl <ja...@tesla.io>]

On Feb 1, 2013, at 3:47 AM, Arnaud Héritier <ah...@gmail.com> wrote:

> My position was to propose the low cost possible solution to have a quick
> fix and not to wait for months.

You realize that disabling this feature allows the potential for a developer to go home, download something in a build with a GAV and go to work where that GAV doesn't correspond to the same thing for whatever reason -- and he will never know or be warned with it disabled. Maybe the JAR is patched and not renamed but does something important for the organization like fix a security problem. This might cause a disparity in how the build behaves in a mild case where he sees something different than the other developers. Worst case is that artifact finds its way into something it's not supposed to and cause a real problem.

Maven currently does not consider the same GAV from two different sources to be the same and for good reason. If we added the logic which asserted they were, in fact, the same JAR like checking the SHA1 I think that would be perfectly reasonable. Turning it off is just not wise.

If you move around between work and home a lot use a repository manager locally. I've done that forever and I don't have any issues aside from having to add the odd proxy repository when there is a repository listed in a POM. I don't consider it a problem and it prevents the problem of mismatched identity. This logic should be improved not neutered. And I'm frankly tired of slapdash changes like this being made in the core without any discussion or review. The last two major changes I've made I've asked other to review my work which I think now with some other incidents of late that would be wise for all changes to the core.

I'm -1 on disabling this feature by default. Fix it properly, using a property to turn it off is half measure which potentially causes users even more severe problems.

> If it could be fixed/configurable in aether it may be the solution to
> follow but I'm not sure about the status of this 3rd party project (eclipse
> migration ...) on which we don't have the hand.
> Seriously I helped and lost MANY hours with this problem because it is hard
> to diagnose.
> I'm sure that many people abandoned to try to understand and just dropped
> their local repo or decided to downgraded to m2 (or to switch to another
> tool).
> I think we can have a lot of similar feedbacks.
> The worst thing is to have another thing that users don't understand (lake
> of documentation ? communication ?)
> The side effect is that changing a repository id (or mirror id) makes maven
> to re-download all the earth (while we are claiming from the beginning that
> Maven won't never download twice a release).
> And when the remote artifact just disappeared it is just a nightmare due to
> the lake of correct logs and this case is easy to have.
> For example in my company I have a profile to let people DL artifacts from
> staging repositories (thus these are releases). It happened that they
> activated it once to test a build and then they rebuild the project without
> the profile (thinking the artifact is in the local repo) and it fails ...
> 
> Sincerely I think I had my worst headaches with maven due to this bug
> 
> 
> 
> On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io> wrote:
> 
>> 
>> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>> 
>>> Hi Olivier,
>>> 
>>> Thx a lot for the fix. It will help a lot the community.
>>> But from my point of view it's perhaps not yet enough.
>>> We should :
>>> 1/ change the default behavior to deactivate this control which is
>>> difficult to understand
>> 
>> I disagree. We may want to change it slightly but it's only a problem for
>> people who flip between Maven a repository manager and without but it's to
>> ensure the identity of a component. I haven't seen a huge number of
>> complaints. I do not want to turn this off. Improve it, sure, but turning
>> it off by default I believe is not the right thing to do.
>> 
>>> 2/ change the error message when this control is activated to clearly
>>> explain that the problem comes from the unavailability of the artifact on
>>> its original remote repo.
>>> 
>>> For me 1/ is mandatory and 2/ a nice to have
>>> 
>>> WDYT ?
>>> 
>>> 
>>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org> wrote:
>>> 
>>>> I have pushed a fix for that.
>>>> Now you can desactivate the enhanced local repository using:
>>>> * new cli option: -slrm,--simple-local-repository-manager
>>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
>>>> 
>>>> will be available for testing here
>>>> https://builds.apache.org/job/maven-3.x/ with build #368
>>>> 
>>>> 
>>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
>>>>> Hi Arnaud,
>>>>> 
>>>>>> +1 to consider the current behavior as a bug.
>>>>>> We should be able to deactivate it easily (and perhaps to have it off
>> by
>>>>>> default to activate it only on CI servers)
>>>>> 
>>>>> :)
>>>>> 
>>>>>> and we should take care to have
>>>>>> a real error message explaining the issue and not a classical
>> dependency
>>>>>> not found while the artifact is in the local repo.
>>>>> 
>>>>> This is exactly filed here:
>>>>> http://jira.codehaus.org/browse/MNG-5185
>>>>> 
>>>>>> 
>>>>>> Arnaud
>>>>> Cheers
>>>>> Jörg
>>>>> 
>>>>> --
>>>>> If know-how becomes know-where, then knowledge gets nowhere.
>>>>> [Jörg Hohwiller]
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Olivier Lamy
>>>> Talend: http://coders.talend.com
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> -----
>>> Arnaud Héritier
>>> http://aheritier.net
>>> Mail/GTalk: aheritier AT gmail DOT com
>>> Twitter/Skype : aheritier
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> Our achievements speak for themselves. What we have to keep track
>> of are our failures, discouragements and doubts. We tend to forget
>> the past difficulties, the many false starts, and the painful
>> groping. We see our past achievements as the end result of a
>> clean forward thrust, and our present difficulties as
>> signs of decline and decay.
>> 
>> -- Eric Hoffer, Reflections on the Human Condition
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> -----
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

  -- Jakob Burckhardt

Re: Pain with MNG-5181 (_maven.repositories)

[Arnaud Héritier <ah...@gmail.com>]

My position was to propose the low cost possible solution to have a quick
fix and not to wait for months.
If it could be fixed/configurable in aether it may be the solution to
follow but I'm not sure about the status of this 3rd party project (eclipse
migration ...) on which we don't have the hand.
Seriously I helped and lost MANY hours with this problem because it is hard
to diagnose.
I'm sure that many people abandoned to try to understand and just dropped
their local repo or decided to downgraded to m2 (or to switch to another
tool).
I think we can have a lot of similar feedbacks.
The worst thing is to have another thing that users don't understand (lake
of documentation ? communication ?)
The side effect is that changing a repository id (or mirror id) makes maven
to re-download all the earth (while we are claiming from the beginning that
Maven won't never download twice a release).
And when the remote artifact just disappeared it is just a nightmare due to
the lake of correct logs and this case is easy to have.
For example in my company I have a profile to let people DL artifacts from
staging repositories (thus these are releases). It happened that they
activated it once to test a build and then they rebuild the project without
the profile (thinking the artifact is in the local repo) and it fails ...

Sincerely I think I had my worst headaches with maven due to this bug



On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <ja...@tesla.io> wrote:

>
> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>
> > Hi Olivier,
> >
> >  Thx a lot for the fix. It will help a lot the community.
> >  But from my point of view it's perhaps not yet enough.
> >  We should :
> >  1/ change the default behavior to deactivate this control which is
> > difficult to understand
>
> I disagree. We may want to change it slightly but it's only a problem for
> people who flip between Maven a repository manager and without but it's to
> ensure the identity of a component. I haven't seen a huge number of
> complaints. I do not want to turn this off. Improve it, sure, but turning
> it off by default I believe is not the right thing to do.
>
> >  2/ change the error message when this control is activated to clearly
> > explain that the problem comes from the unavailability of the artifact on
> > its original remote repo.
> >
> >  For me 1/ is mandatory and 2/ a nice to have
> >
> > WDYT ?
> >
> >
> > On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org> wrote:
> >
> >> I have pushed a fix for that.
> >> Now you can desactivate the enhanced local repository using:
> >> * new cli option: -slrm,--simple-local-repository-manager
> >> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
> >>
> >> will be available for testing here
> >> https://builds.apache.org/job/maven-3.x/ with build #368
> >>
> >>
> >> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
> >>> Hi Arnaud,
> >>>
> >>>> +1 to consider the current behavior as a bug.
> >>>> We should be able to deactivate it easily (and perhaps to have it off
> by
> >>>> default to activate it only on CI servers)
> >>>
> >>> :)
> >>>
> >>>> and we should take care to have
> >>>> a real error message explaining the issue and not a classical
> dependency
> >>>> not found while the artifact is in the local repo.
> >>>
> >>> This is exactly filed here:
> >>> http://jira.codehaus.org/browse/MNG-5185
> >>>
> >>>>
> >>>> Arnaud
> >>> Cheers
> >>>  Jörg
> >>>
> >>> --
> >>> If know-how becomes know-where, then knowledge gets nowhere.
> >>>  [Jörg Hohwiller]
> >>>
> >>
> >>
> >>
> >> --
> >> Olivier Lamy
> >> Talend: http://coders.talend.com
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > -----
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Our achievements speak for themselves. What we have to keep track
> of are our failures, discouragements and doubts. We tend to forget
> the past difficulties, the many false starts, and the painful
> groping. We see our past achievements as the end result of a
> clean forward thrust, and our present difficulties as
> signs of decline and decay.
>
>  -- Eric Hoffer, Reflections on the Human Condition
>
>
>
>
>
>


-- 
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Pain with MNG-5181 (_maven.repositories)

[Benson Margulies <bi...@gmail.com>]

On Fri, Feb 1, 2013 at 3:47 AM, Jason van Zyl <ja...@tesla.io> wrote:
>
> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>
>> Hi Olivier,
>>
>>  Thx a lot for the fix. It will help a lot the community.
>>  But from my point of view it's perhaps not yet enough.
>>  We should :
>>  1/ change the default behavior to deactivate this control which is
>> difficult to understand
>
> I disagree. We may want to change it slightly but it's only a problem for people who flip between Maven a repository manager and without but it's to ensure the identity of a component. I haven't seen a huge number of complaints. I do not want to turn this off. Improve it, sure, but turning it off by default I believe is not the right thing to do.


Here's when it has killed me. There's a corporate Nexus at my office.
It has a policy that cuts off access to random repos. Every so often,
something I'm doing at Apache involves a project that requires
artifacts from some, well, random repo. So I keep two Maven home dirs
around: one has a settings.xml that goes corporate, one that does not.

Eventually, for the obvious reason, I set them up to use two different
local repos. I wish I didn't have to.


>
>>  2/ change the error message when this control is activated to clearly
>> explain that the problem comes from the unavailability of the artifact on
>> its original remote repo.
>>
>>  For me 1/ is mandatory and 2/ a nice to have
>>
>> WDYT ?
>>
>>
>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org> wrote:
>>
>>> I have pushed a fix for that.
>>> Now you can desactivate the enhanced local repository using:
>>> * new cli option: -slrm,--simple-local-repository-manager
>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
>>>
>>> will be available for testing here
>>> https://builds.apache.org/job/maven-3.x/ with build #368
>>>
>>>
>>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
>>>> Hi Arnaud,
>>>>
>>>>> +1 to consider the current behavior as a bug.
>>>>> We should be able to deactivate it easily (and perhaps to have it off by
>>>>> default to activate it only on CI servers)
>>>>
>>>> :)
>>>>
>>>>> and we should take care to have
>>>>> a real error message explaining the issue and not a classical dependency
>>>>> not found while the artifact is in the local repo.
>>>>
>>>> This is exactly filed here:
>>>> http://jira.codehaus.org/browse/MNG-5185
>>>>
>>>>>
>>>>> Arnaud
>>>> Cheers
>>>>  Jörg
>>>>
>>>> --
>>>> If know-how becomes know-where, then knowledge gets nowhere.
>>>>  [Jörg Hohwiller]
>>>>
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> --
>> -----
>> Arnaud Héritier
>> http://aheritier.net
>> Mail/GTalk: aheritier AT gmail DOT com
>> Twitter/Skype : aheritier
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Our achievements speak for themselves. What we have to keep track
> of are our failures, discouragements and doubts. We tend to forget
> the past difficulties, the many false starts, and the painful
> groping. We see our past achievements as the end result of a
> clean forward thrust, and our present difficulties as
> signs of decline and decay.
>
>  -- Eric Hoffer, Reflections on the Human Condition
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Pain with MNG-5181 (_maven.repositories)

[Jason van Zyl <ja...@tesla.io>]

On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <ah...@gmail.com> wrote:

> Hi Olivier,
> 
>  Thx a lot for the fix. It will help a lot the community.
>  But from my point of view it's perhaps not yet enough.
>  We should :
>  1/ change the default behavior to deactivate this control which is
> difficult to understand

I disagree. We may want to change it slightly but it's only a problem for people who flip between Maven a repository manager and without but it's to ensure the identity of a component. I haven't seen a huge number of complaints. I do not want to turn this off. Improve it, sure, but turning it off by default I believe is not the right thing to do.

>  2/ change the error message when this control is activated to clearly
> explain that the problem comes from the unavailability of the artifact on
> its original remote repo.
> 
>  For me 1/ is mandatory and 2/ a nice to have
> 
> WDYT ?
> 
> 
> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org> wrote:
> 
>> I have pushed a fix for that.
>> Now you can desactivate the enhanced local repository using:
>> * new cli option: -slrm,--simple-local-repository-manager
>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
>> 
>> will be available for testing here
>> https://builds.apache.org/job/maven-3.x/ with build #368
>> 
>> 
>> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
>>> Hi Arnaud,
>>> 
>>>> +1 to consider the current behavior as a bug.
>>>> We should be able to deactivate it easily (and perhaps to have it off by
>>>> default to activate it only on CI servers)
>>> 
>>> :)
>>> 
>>>> and we should take care to have
>>>> a real error message explaining the issue and not a classical dependency
>>>> not found while the artifact is in the local repo.
>>> 
>>> This is exactly filed here:
>>> http://jira.codehaus.org/browse/MNG-5185
>>> 
>>>> 
>>>> Arnaud
>>> Cheers
>>>  Jörg
>>> 
>>> --
>>> If know-how becomes know-where, then knowledge gets nowhere.
>>>  [Jörg Hohwiller]
>>> 
>> 
>> 
>> 
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 
> 
> 
> -- 
> -----
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.

 -- Eric Hoffer, Reflections on the Human Condition

Re: Pain with MNG-5181 (_maven.repositories)

[Wayne Fay <wa...@gmail.com>]

>   1/ change the default behavior to deactivate this control which is
> difficult to understand
>   2/ change the error message when this control is activated to clearly
> explain that the problem comes from the unavailability of the artifact on
> its original remote repo.
>
>   For me 1/ is mandatory and 2/ a nice to have

I am in general agreement but I would say 2 is must-do and 1 is
probably-must-do. I've had to help a bunch of people who ran into this
problem in the last few months. If the error message was better (with
a simple direction to follow to disable it), then I'm less sure about
1 being a must-do.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Pain with MNG-5181 (_maven.repositories)

[Arnaud Héritier <ah...@gmail.com>]

Hi Olivier,

  Thx a lot for the fix. It will help a lot the community.
  But from my point of view it's perhaps not yet enough.
  We should :
  1/ change the default behavior to deactivate this control which is
difficult to understand
  2/ change the error message when this control is activated to clearly
explain that the problem comes from the unavailability of the artifact on
its original remote repo.

  For me 1/ is mandatory and 2/ a nice to have

WDYT ?


On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <ol...@apache.org> wrote:

> I have pushed a fix for that.
> Now you can desactivate the enhanced local repository using:
> * new cli option: -slrm,--simple-local-repository-manager
> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
>
> will be available for testing here
> https://builds.apache.org/job/maven-3.x/ with build #368
>
>
> 2013/1/31 Jörg Hohwiller <jo...@j-hohwiller.de>:
> > Hi Arnaud,
> >
> >> +1 to consider the current behavior as a bug.
> >> We should be able to deactivate it easily (and perhaps to have it off by
> >> default to activate it only on CI servers)
> >
> > :)
> >
> >> and we should take care to have
> >> a real error message explaining the issue and not a classical dependency
> >> not found while the artifact is in the local repo.
> >
> > This is exactly filed here:
> > http://jira.codehaus.org/browse/MNG-5185
> >
> >>
> >> Arnaud
> > Cheers
> >   Jörg
> >
> > --
> > If know-how becomes know-where, then knowledge gets nowhere.
> >   [Jörg Hohwiller]
> >
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier