Re: Pain with MNG-5181 (_maven.repositories)
Andreas Gudian wrote: Am Freitag, 1. Februar 2013 schrieb Jason van Zyl : On Jan 31, 2013, at 7:13 PM, Arnaud Héritier aherit...@gmail.comjavascript:; 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. How about turning it into a warning by default and only fail if you enable some meaningful option (or implicitly in some plugins such as the release plugin). But I must admit that I don't really have a use case in mind where failing is crucial. We have a private plugin from an internal repository which has a goal that is executed during the build and a goal to generate a report. Unfortunately the jar of the plugin can no longer be resolved when it should generate the report. As it turns out, the site plugin is too old (3.0-beta-3). However, any newer version has a bug (MSITE-604) and site:deploy fails i.e. we cannot release with it. Catch-22. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pain with MNG-5181 (_maven.repositories)
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 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
Re: Pain with MNG-5181 (_maven.repositories)
+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 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. 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
Re: [VOTE] Plugins parent 24 and Shared parent 19
+1 2013/1/30 Olivier Lamy ol...@apache.org: Hi, I'd like to release Plugins parent 24 and Shared parent 19. Staging repository: https://repository.apache.org/content/repositories/maven-172/ Diffs: * Plugins parent 24: http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-24/pom.xml?r1=HEADr2=1371605diff_format=h * Shared parent 19: http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-19/pom.xml?r1=HEADr2=1371614diff_format=h Vote open for 72H. [+1] [0] [-1] -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- 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
Re: [VOTE] Plugins parent 24 and Shared parent 19
+0 I have to agree with Anders: m-invoker-p 1.7 is missing groovy´s XmlSlurper and 1.8 is really powerful compared to its previous versions Robert Op Thu, 31 Jan 2013 16:54:36 +0100 schreef Anders Hammar and...@hammar.net: 0 It would have been good to get v1.8 of m-invoker-p in maven-plugins while we're at it. /Anders On Wed, Jan 30, 2013 at 12:40 AM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Plugins parent 24 and Shared parent 19. Staging repository: https://repository.apache.org/content/repositories/maven-172/ Diffs: * Plugins parent 24: http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-24/pom.xml?r1=HEADr2=1371605diff_format=h * Shared parent 19: http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-19/pom.xml?r1=HEADr2=1371614diff_format=h Vote open for 72H. [+1] [0] [-1] -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Plugins parent 24 and Shared parent 19
Nothing prevent you to use this version with overriding that in a pom if you really need it. We are talking here only about a pom ! which doesn't have any impact neither real value for end users. Perso if I prefer to concentrate my energy and use my time for end users rather than for a pom. -- Olivier 2013/2/1 Robert Scholte rfscho...@apache.org: +0 I have to agree with Anders: m-invoker-p 1.7 is missing groovy´s XmlSlurper and 1.8 is really powerful compared to its previous versions Robert Op Thu, 31 Jan 2013 16:54:36 +0100 schreef Anders Hammar and...@hammar.net: 0 It would have been good to get v1.8 of m-invoker-p in maven-plugins while we're at it. /Anders On Wed, Jan 30, 2013 at 12:40 AM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Plugins parent 24 and Shared parent 19. Staging repository: https://repository.apache.org/content/repositories/maven-172/ Diffs: * Plugins parent 24: http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-24/pom.xml?r1=HEADr2=1371605diff_format=h * Shared parent 19: http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-19/pom.xml?r1=HEADr2=1371614diff_format=h Vote open for 72H. [+1] [0] [-1] -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Plugins parent 24 and Shared parent 19
Sure I know. But if plugins upgrade to this new parent and were depending on extra groovy-utils, they will first face breaking integration tests. Next they have to know they need to use either m-invoker-p 1.6 or 1.8. And with the parent 25 they have to remove it again since it should inherit the version. I don't have the numbers, but I think there are enough plugins which will fail just because of this. I'm not giving a negative vote, I know what to do. I just want the upgrades to go as smooth as possible. Robert Op Fri, 01 Feb 2013 21:57:22 +0100 schreef Olivier Lamy ol...@apache.org: Nothing prevent you to use this version with overriding that in a pom if you really need it. We are talking here only about a pom ! which doesn't have any impact neither real value for end users. Perso if I prefer to concentrate my energy and use my time for end users rather than for a pom. -- Olivier 2013/2/1 Robert Scholte rfscho...@apache.org: +0 I have to agree with Anders: m-invoker-p 1.7 is missing groovy´s XmlSlurper and 1.8 is really powerful compared to its previous versions Robert Op Thu, 31 Jan 2013 16:54:36 +0100 schreef Anders Hammar and...@hammar.net: 0 It would have been good to get v1.8 of m-invoker-p in maven-plugins while we're at it. /Anders On Wed, Jan 30, 2013 at 12:40 AM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Plugins parent 24 and Shared parent 19. Staging repository: https://repository.apache.org/content/repositories/maven-172/ Diffs: * Plugins parent 24: http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-24/pom.xml?r1=HEADr2=1371605diff_format=h * Shared parent 19: http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-19/pom.xml?r1=HEADr2=1371614diff_format=h Vote open for 72H. [+1] [0] [-1] -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Plugins parent 24 and Shared parent 19
+1 Regards, Hervé Le mercredi 30 janvier 2013 00:40:43 Olivier Lamy a écrit : Hi, I'd like to release Plugins parent 24 and Shared parent 19. Staging repository: https://repository.apache.org/content/repositories/maven-172/ Diffs: * Plugins parent 24: http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-24/pom.xml?r1= HEADr2=1371605diff_format=h * Shared parent 19: http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-19/po m.xml?r1=HEADr2=1371614diff_format=h Vote open for 72H. [+1] [0] [-1] -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Plugins parent 24 and Shared parent 19
On Fri, 1 Feb 2013 17:34:59 +0100 Olivier Lamy ol...@apache.org wrote: +1 Keep fighting ;) thanks, tony. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
