On Feb 1, 2013, at 3:47 AM, Arnaud Héritier <aherit...@gmail.com> wrote:
> My position was to propose the low cost possible solution to have a quick > fix and not to wait for months. You realize that disabling this feature allows the potential for a developer to go home, download something in a build with a GAV and go to work where that GAV doesn't correspond to the same thing for whatever reason -- and he will never know or be warned with it disabled. Maybe the JAR is patched and not renamed but does something important for the organization like fix a security problem. This might cause a disparity in how the build behaves in a mild case where he sees something different than the other developers. Worst case is that artifact finds its way into something it's not supposed to and cause a real problem. Maven currently does not consider the same GAV from two different sources to be the same and for good reason. If we added the logic which asserted they were, in fact, the same JAR like checking the SHA1 I think that would be perfectly reasonable. Turning it off is just not wise. If you move around between work and home a lot use a repository manager locally. I've done that forever and I don't have any issues aside from having to add the odd proxy repository when there is a repository listed in a POM. I don't consider it a problem and it prevents the problem of mismatched identity. This logic should be improved not neutered. And I'm frankly tired of slapdash changes like this being made in the core without any discussion or review. The last two major changes I've made I've asked other to review my work which I think now with some other incidents of late that would be wise for all changes to the core. I'm -1 on disabling this feature by default. Fix it properly, using a property to turn it off is half measure which potentially causes users even more severe problems. > 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 <ja...@tesla.io> wrote: > >> >> On Jan 31, 2013, at 7:13 PM, Arnaud Héritier <aherit...@gmail.com> 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 <ol...@apache.org> 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 <jo...@j-hohwiller.de>: >>>>> 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: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >>> >>> >>> -- >>> ----- >>> 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 Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
