On 16 January 2012 15:45, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > 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
You can also Google for: maven-metadata-public-snapshot.xml ': expected START_TAG or END_TAG not TEXT (position: TEXT seen That will list all the people complaining. To see this most easily, find your favorite Maven Plugin, using Maven 3.0.3 run "mvn clean install" on a -SNAPSHOT version using Maven 2.2.1 run "mvn groupId:artifactId:version-SNAPSHOT:goal" and watch the blow-up >> >>> 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
