On 15 January 2012 11:11, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > Le samedi 14 janvier 2012 20:22:15 Stephen Connolly a écrit : >> personally i think we need to draw a line in the sand for all plugins... >> 2.2.1 is the best line at the moment imho... > +1 > >> >> 2.1.0 and 2.2.0 are not recommended versions, and drawing a line above them >> makes our message to users that much cleaner. >> >> the only other thing we maybe should do is roll a 2.2.2 that doesn't bomb >> out if 3.0.3 has pulled snapshot dependencies into the same local repo... > is there a Jira issue for this?
Have not seen one specifically, the issue that is the RCA is http://jira.codehaus.org/browse/MNG-4452 >From the latest comment http://jira.codehaus.org/browse/MNG-4452?focusedCommentId=285802&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-285802 you can see that 2.2.1 has issues (which I can confirm from my testing of versions-maven-plugin in preparation of it's 1.3 release > >> i >> may look into that myself... i think it would be fine for it to ignore that >> extra xml entries in the metadata (least change in behaviour) so only >> change from 2.2.1 would be the more relaxed metadata parsing... if anyone >> knows any criticals i would more likely see those in a 2.2.3 or 2.3 ie i >> wouldn't be release manager for such a release ;-) >> >> - Stephen >> >> --- >> Sent from my Android phone, so random spelling mistakes, random nonsense >> words and other nonsense are a direct result of using swype to type on the >> screen >> >> On 14 Jan 2012 15:45, "Robert Scholte" <apa...@sourcegrounds.com> wrote: >> > I've fixed MCHECKSTYLE-170 and tried to apply some shading. >> > The separation of api/interfaces versus implementation is not done well >> > in Doxia. >> > This would mean, that the shade-plugin will need a lot of configuration, >> > which also needs to be maintained if there are new Doxia-classes. >> > So for plugins with only reporting-goals the requirement for Maven-2.2.1 >> > seems to be the best solution. >> > >> > -Robert >> > >> > On Sat, 14 Jan 2012 00:10:45 +0100, Dennis Lundberg <denn...@apache.org> >> > >> > wrote: >> > On 2012-01-13 20:43, Robert Scholte wrote: >> >>> My guess would be that with relocation it wouldn't matter.[1] >> >>> I'd like to confirm this with the maven-checkstyle-plugin project, >> >>> but >> >>> unfortunately a lot of unit-tests are failing on my machine (win7 + >> >>> jdk6 + any M2/M3) >> >> >> >> I can confirm these test errors and failures on Win 7, Java 5 and >> >> Maven >> >> 2.2.1/3.0.3. >> >> >> >> On Ubuntu with Java 5 and Maven 2.2.1/3.0.3 it works though. >> >> >> >> Created an issue in JIRA to track it: >> >> http://jira.codehaus.org/**browse/MCHECKSTYLE-170<http://jira.codehaus >> >> .org/browse/MCHECKSTYLE-170>>> >> >> -Robert >> >> >> >>> [1] >> >>> http://maven.apache.org/**plugins/maven-shade-plugin/** >> >>> examples/class-relocation.html<http://maven.apache.org/plugins/maven >> >>> -shade-plugin/examples/class-relocation.html> >> >>> >> >>> >> >>> On Thu, 12 Jan 2012 22:59:36 +0100, Dennis Lundberg >> >>> <denn...@apache.org>>>> >> >>> wrote: >> >>> Hi >> >>> >> >>>> Can it work? I haven't had much experience with shading, but I was >> >>>> under the impression that it is a way to hide classes from >> >>>> Maven's class loader. What we really want in this case is a way >> >>>> to *insert* newer versions of classes into Maven's class loader. >> >>>> Don't know if that can be done... >> >>>> >> >>>> On 2012-01-12 00:12, Robert Scholte wrote: >> >>>>> What about plugins containing both build and report goals? >> >>>>> If the suggested shading of Doxia will work, I'd prefer that >> >>>>> option. >> >>>>> >> >>>>> -Robert >> >>>>> >> >>>>> On Wed, 11 Jan 2012 23:53:57 +0100, Barrie Treloar >> >>>>> <baerr...@gmail.com>>>>> >> >>>>> wrote: >> >>>>> On Thu, Jan 12, 2012 at 9:15 AM, Stephen Connolly >> >>>>> >> >>>>>> <stephen.alan.connolly@gmail.**com >> >>>>>> <stephen.alan.conno...@gmail.com>>>>>>>> >> >>>>>> wrote: >> >>>>>>> +1 >> >>>>>> >> >>>>>> +1 >> >>>>>> >> >>>>>> ------------------------------**------------------------------ >> >>>>>> ** >> >>>>>> --------- >> >>>>>> To unsubscribe, e-mail: >> >>>>>> dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apac >> >>>>>> he.org> For additional commands, e-mail: >> >>>>>> dev-h...@maven.apache.org >> >>>>> >> >>>>> ------------------------------**------------------------------** >> >>>>> --------- >> >>>>> To unsubscribe, e-mail: >> >>>>> dev-unsubscribe@maven.apache.**org<dev-unsubscribe@maven.apache >> >>>>> .org> For additional commands, e-mail: dev-h...@maven.apache.org >> >>> >> >>> ------------------------------**------------------------------** >> >>> --------- >> >>> To unsubscribe, e-mail: >> >>> dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org >> >>> > For additional commands, e-mail: dev-h...@maven.apache.org >> > >> > ------------------------------**------------------------------**-------- >> > - >> > To unsubscribe, e-mail: >> > dev-unsubscribe@maven.apache.**org<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
