+1 on Arnaud's comments. The main problem with this "feature" is that it is not documented thus I can't explain the real reason why Maven download several times released artifacts and this causes members of the Maven bashing group to grow
Jeff On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier <[email protected]> wrote: > My position was to propose the low cost possible solution to have a quick > fix and not to wait for months. > If it could be fixed/configurable in aether it may be the solution to > follow but I'm not sure about the status of this 3rd party project (eclipse > migration ...) on which we don't have the hand. > Seriously I helped and lost MANY hours with this problem because it is hard > to diagnose. > I'm sure that many people abandoned to try to understand and just dropped > their local repo or decided to downgraded to m2 (or to switch to another > tool). > I think we can have a lot of similar feedbacks. > The worst thing is to have another thing that users don't understand (lake > of documentation ? communication ?) > The side effect is that changing a repository id (or mirror id) makes maven > to re-download all the earth (while we are claiming from the beginning that > Maven won't never download twice a release). > And when the remote artifact just disappeared it is just a nightmare due to > the lake of correct logs and this case is easy to have. > For example in my company I have a profile to let people DL artifacts from > staging repositories (thus these are releases). It happened that they > activated it once to test a build and then they rebuild the project without > the profile (thinking the artifact is in the local repo) and it fails ... > > Sincerely I think I had my worst headaches with maven due to this bug > > > > On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <[email protected]> wrote: > > > > > On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <[email protected]> > wrote: > > > > > Hi Olivier, > > > > > > Thx a lot for the fix. It will help a lot the community. > > > But from my point of view it's perhaps not yet enough. > > > We should : > > > 1/ change the default behavior to deactivate this control which is > > > difficult to understand > > > > I disagree. We may want to change it slightly but it's only a problem for > > people who flip between Maven a repository manager and without but it's > to > > ensure the identity of a component. I haven't seen a huge number of > > complaints. I do not want to turn this off. Improve it, sure, but turning > > it off by default I believe is not the right thing to do. > > > > > 2/ change the error message when this control is activated to clearly > > > explain that the problem comes from the unavailability of the artifact > on > > > its original remote repo. > > > > > > For me 1/ is mandatory and 2/ a nice to have > > > > > > WDYT ? > > > > > > > > > On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <[email protected]> > wrote: > > > > > >> I have pushed a fix for that. > > >> Now you can desactivate the enhanced local repository using: > > >> * new cli option: -slrm,--simple-local-repository-manager > > >> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true > > >> > > >> will be available for testing here > > >> https://builds.apache.org/job/maven-3.x/ with build #368 > > >> > > >> > > >> 2013/1/31 Jörg Hohwiller <[email protected]>: > > >>> Hi Arnaud, > > >>> > > >>>> +1 to consider the current behavior as a bug. > > >>>> We should be able to deactivate it easily (and perhaps to have it > off > > by > > >>>> default to activate it only on CI servers) > > >>> > > >>> :) > > >>> > > >>>> and we should take care to have > > >>>> a real error message explaining the issue and not a classical > > dependency > > >>>> not found while the artifact is in the local repo. > > >>> > > >>> This is exactly filed here: > > >>> http://jira.codehaus.org/browse/MNG-5185 > > >>> > > >>>> > > >>>> Arnaud > > >>> Cheers > > >>> Jörg > > >>> > > >>> -- > > >>> If know-how becomes know-where, then knowledge gets nowhere. > > >>> [Jörg Hohwiller] > > >>> > > >> > > >> > > >> > > >> -- > > >> Olivier Lamy > > >> Talend: http://coders.talend.com > > >> http://twitter.com/olamy | http://linkedin.com/in/olamy > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > >> > > > > > > > > > -- > > > ----- > > > Arnaud Héritier > > > http://aheritier.net > > > Mail/GTalk: aheritier AT gmail DOT com > > > Twitter/Skype : aheritier > > > > Thanks, > > > > Jason > > > > ---------------------------------------------------------- > > Jason van Zyl > > Founder & CTO, Sonatype > > Founder, Apache Maven > > http://twitter.com/jvanzyl > > --------------------------------------------------------- > > > > Our achievements speak for themselves. What we have to keep track > > of are our failures, discouragements and doubts. We tend to forget > > the past difficulties, the many false starts, and the painful > > groping. We see our past achievements as the end result of a > > clean forward thrust, and our present difficulties as > > signs of decline and decay. > > > > -- Eric Hoffer, Reflections on the Human Condition > > > > > > > > > > > > > > > -- > ----- > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier > -- Jeff MAURY "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
