maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Pain with MNG-5181 (_maven.repositories)
Date Mon, 04 Feb 2013 00:38:09 GMT
Cool, fair enough.

On Feb 3, 2013, at 7:31 PM, Hervé BOUTEMY <> 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 <> 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:
>>> For additional commands, e-mail:
>> Thanks,
>> Jason
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> ---------------------------------------------------------
>> To do two things at once is to do neither.
>> -- Publilius Syrus, Roman slave, first century B.C.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message