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 <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > 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: [email protected] For additional commands, e-mail: [email protected]
