Well actually I'd say force people to use 2.2.2 after rolling a 2.2.2 that does not barf on the 3.0.3 metadata in local repo... such a 2.2.2 does not need to understand the extra metadata, just not barf on it (i.e. copy the 2.2.1 tag, make the metadata forgiving, release 2.2.2 so that the changes are absolutely minimal)
But other than that, yes that is my point On 16 January 2012 17:25, Robert Scholte <apa...@sourcegrounds.com> wrote: > So what you're actually saying: > Let's force people to NOT use Maven-2.1.0 of 2.2.0 by setting the > prerequisite for maven to 2.2.1 > And hence, we get the Doxia verison we want. > That would solve two problems at once. > > -Robert > > > On Mon, 16 Jan 2012 16:47:39 +0100, Stephen Connolly > <stephen.alan.conno...@gmail.com> wrote: > >> 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 > > > --------------------------------------------------------------------- > 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
