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 Sun, 03 Feb 2013 18:37:13 GMT

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:



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.

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