On Feb 3, 2013, at 4:12 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> Le samedi 2 février 2013 22:39:55 Jason van Zyl a écrit : >> 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. > is it really a part of the feature? I didn't understand that this feature > calculated something like a checksum of an artifact and could store the > artifact multiple times > > I thought it was only to avoid for example downloading a dependency from a > plugin then use it in component dependency (ie the use case I was expecting): > that's what I understanding when reading aether-impl's > EnhancedLocalRepositoryManager javadoc and source (in source, since this > class > is package private, then not published in javadoc) > > Am I wrong? Do I miss something? > h1. Enhanced Remote Repository Support The feature verifies that the remote repositories configured for the current build can be used to successfully resolve the artifact in question. If you retrieved an artifact in the past from Central and now changed your build to only know about Nexus and it doesn't have any knowledge of that artifact then the build is going to fail. Put differently, if you purged your local repo, your build won't work either. Neglecting offline mode, the goal is to ensure that the resolution works if it could be performed using a clean local repo with the current configuration. Giving confidence that co-workers can reproduce the build and not depend on some artifact magically being pulled down into your local repository in the past which is nowhere to be found in the configured remote repository. --- So the upshot is that with this feature off you will happily build all day, but when you commit your CI will fail and anyone you're working with will also get failures because the artifact is not available in your shared setup. I have identity management in my code but the base feature as it exists in Maven asserts the availability of the artifact with the given repository setup. I do not see what value there is in even allowing this feature to be turned off ever. It can only cause inconsistencies. > >> >> 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. > Turning it off is just a workaround to get the same behaviour than Maven 2, > which is not perfect but that everybody understand, to help people while > we're > working to understand the feature ourselves (yes, ourselves...) and document > it sufficiently for end-users What Maven 2.x does is wrong because it can lead to "works for me" while not working for anyone else. > >> >> 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. > +1 but if we can't improve it before the next release, disabling it can be a > temporary solution since this feature is really hard for users > 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. 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. The failure occurs when the artifact is not available remotely, why would you let someone carry on? Anyone using the same configuration with a clean local repository will have a build that fails. This feature protects users, removing this makes it easier to create inconsistencies. >> 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. As per the explanation above the feature where the goal is to attain consistency across a team: I have no qualms with what Benjamin did. He fully understood what he was doing and was an effort to make sure a build works for everyone. If you're saying that no one really understands what the feature is for and yet optionally disabled it, I would say is fairly uninformed. 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. There are better ways to achieve creating an offline repository without allowing undesirable behaviour in Maven. Letting anything build in one place where we know it won't work in another is bad. That's the basis of this feature and turning it off just let's people cause harm across a team. > > >> 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. > nice, it isn't disabled by default, Olivier did a nice job to not break > anything > I don't see why you would ever disable this. It covers up other problems you have and just creates more issues. > >> Fix it properly, using a >> property to turn it off is half measure which potentially causes users even >> more severe problems. > +1 > I'm trying to find a better way for a long time now, that's why I tried to > write maven-aether-provider unit tests as a first step > but for the moment, I couldn't find a solution: thank you Olivier for finding > some workaround, even if not ideal > if anydoby has a clue on how to solve the problem, please explain (and "just > do it" is not an explanation) > It currently does the right thing. If an artifact is not resolvable with the current setup you're just masking potential problems. It needs to remain off by default. Most people will never find it and likely can't do much harm. There is no real problem and putting in code without really understanding the issue or what the feature is intended to do is sub-optimal at best. > >>> 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 >> >> 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 > > --------------------------------------------------------------------- > 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
