maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: Pain with MNG-5181 (_maven.repositories)
Date Mon, 04 Feb 2013 00:31:32 GMT
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.boutemy@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


Mime
View raw message