Cool, fair enough. On Feb 3, 2013, at 7:31 PM, Hervé BOUTEMY <herve.bout...@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 <herve.bout...@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-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@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-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@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
