Re: Eclipse plugin ITs was Re: [VOTE] Release Maven Eclipse Plugin version 2.9
On Mon, Jan 16, 2012 at 12:34 AM, Barrie Treloar baerr...@gmail.com wrote: 2012/1/16 Arnaud Héritier aherit...@gmail.com: Thanks a lot for this hard wok Barrie yes it was my problem too Robert. ITs are now very difficult to use/maintain and sadly are covering only the fact that what we generate is always the same and not that it is working in eclipse. As far as I remember this is the larger plugin we have in lines of codes and also the dirtiest one as it was built from many many contributors (because of the variety of usages and eclipse versions) Since that, I had the chance to switch from eclipse to intellij and it solved all my issues. lol. Well what black magic is intellij doing that makes using maven better? In fact my disagreement with eclipse is over than only its Maven integration I didn't use it now for more than one year thus I cannot tell how it is going now but my impediment was to have to choose between * m2eclipse which supported a little subset of eclipse features (WTP integration didn't work well before JBoss start to investigate on it, ...), which was slow/unusable for large projects but which provided for what it supported a good developer experience. * maven-eclipse-plugin that had a larger set of feature but that was broken in many points like the dependency management and its inability to import parent/aggregators POMs. Nowadays I'm using IntelliJ which has a transparent integration (I just open a Maven project) and supports large projects. I don't use anymore a JEE integration thus I don't know if it is better or worst than eclipse with WTP. There is the option to switch to m2e. I cant do that for some of my projects because they are Eclipse RCP 3.2 projects that are bodge anyway. m-e-p works well enough. Yes, it was I maintained it also. Its worse than you summarize because: * it does its own dependency analysis because there was no standard way of exposing that before (refactoring to use aether is an option) = yes it is just horrible. But remember why it doesn't use the native maven dep management : it is because you want to be able to import a project that has its dependencies (or more generally some descriptors) broken. I think it's always no possible even with aether to have a mode where it loads what it can. I don't remember how is the behavior of m2e or intellij in that case. I didn't test it for a long time. * the ITs were built at the time where there was no IT standard yes :( * there is support for eclipse-like environments (RAD, etc) which is even harder to maintain yes, and like I said, ITs are almost useless because I had several times the case that even if we continued to generate the same thing, eclipse didn't support it after an upgrade. And sadly for all these configuration files, there is no documentation (AFAIR) and are considered as an internal stuff from eclipse point of view. These aren't APIs that we can rely on. * some OSGi support which is using deprecated feature sets and is impossible to maintain because there are no ITs or use cases for it. yes This list is probably a part of the reason that Jason suggested retiring plugins. (This one is sporadically maintained but it still works as advertised) yes, but I'm not agree to retire it as far as we have few people like you involved in it because it continues to be used and probably it continues to have more users than m2eclipse Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Eclipse plugin ITs was Re: [VOTE] Release Maven Eclipse Plugin version 2.9
The marriage of eclipse and maven poses fundamental challenges that don't exist for Intellij or Netbeans. Of the three major Java IDE's, only Eclipse incorporates its own classpath and compiler system. IJ and NB 'just run maven' and analyze the output for display. Eclipse, on the other hand, actually compiles. Further, Eclipse builds WAR files, and runs tools like checkstyle, pmd, and findbugs via its plugin architecture -- typically with an entirely different configuration system than maven's. Each of m-e-p and m2e is an attempt to bridge these gaps. m-e-p can't solve the problem that eclipse has one classpath and maven has two, nor the problem of bridging configuration one plugin at a time. m2e, on the other hand, has a very difficult hill to climb. mvn and eclipse each has a complex class loader system. At best, the result of running maven inside the eclipse jvm is an even more gigantic thirst for memory (and particularly permgen space). m2e's long-term success depends on eclipse changes to accomodate the maven classpath model. It's also just a giant effort of a small group of people. Dealing with the Eclipse release train system doesn't make their life any easier, either. The net result is that many people find IJ, or even NB, to provide a less frustrating experience. 2012/1/16 Arnaud Héritier aherit...@gmail.com: On Mon, Jan 16, 2012 at 12:34 AM, Barrie Treloar baerr...@gmail.com wrote: 2012/1/16 Arnaud Héritier aherit...@gmail.com: Thanks a lot for this hard wok Barrie yes it was my problem too Robert. ITs are now very difficult to use/maintain and sadly are covering only the fact that what we generate is always the same and not that it is working in eclipse. As far as I remember this is the larger plugin we have in lines of codes and also the dirtiest one as it was built from many many contributors (because of the variety of usages and eclipse versions) Since that, I had the chance to switch from eclipse to intellij and it solved all my issues. lol. Well what black magic is intellij doing that makes using maven better? In fact my disagreement with eclipse is over than only its Maven integration I didn't use it now for more than one year thus I cannot tell how it is going now but my impediment was to have to choose between * m2eclipse which supported a little subset of eclipse features (WTP integration didn't work well before JBoss start to investigate on it, ...), which was slow/unusable for large projects but which provided for what it supported a good developer experience. * maven-eclipse-plugin that had a larger set of feature but that was broken in many points like the dependency management and its inability to import parent/aggregators POMs. Nowadays I'm using IntelliJ which has a transparent integration (I just open a Maven project) and supports large projects. I don't use anymore a JEE integration thus I don't know if it is better or worst than eclipse with WTP. There is the option to switch to m2e. I cant do that for some of my projects because they are Eclipse RCP 3.2 projects that are bodge anyway. m-e-p works well enough. Yes, it was I maintained it also. Its worse than you summarize because: * it does its own dependency analysis because there was no standard way of exposing that before (refactoring to use aether is an option) = yes it is just horrible. But remember why it doesn't use the native maven dep management : it is because you want to be able to import a project that has its dependencies (or more generally some descriptors) broken. I think it's always no possible even with aether to have a mode where it loads what it can. I don't remember how is the behavior of m2e or intellij in that case. I didn't test it for a long time. * the ITs were built at the time where there was no IT standard yes :( * there is support for eclipse-like environments (RAD, etc) which is even harder to maintain yes, and like I said, ITs are almost useless because I had several times the case that even if we continued to generate the same thing, eclipse didn't support it after an upgrade. And sadly for all these configuration files, there is no documentation (AFAIR) and are considered as an internal stuff from eclipse point of view. These aren't APIs that we can rely on. * some OSGi support which is using deprecated feature sets and is impossible to maintain because there are no ITs or use cases for it. yes This list is probably a part of the reason that Jason suggested retiring plugins. (This one is sporadically maintained but it still works as advertised) yes, but I'm not agree to retire it as far as we have few people like you involved in it because it continues to be used and probably it continues to have more users than m2eclipse Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands,
Re: [CALL FOR TEST] Apache Maven 3.0.4-RC5 staged
Hello, So it looks we don't have any issues here. I will proceed a non RC release procedure tomorrow. Thanks for your testing time ! 2012/1/11 Robert Scholte apa...@sourcegrounds.com: looking good. Tested on a lot of mojo projects. -Robert On Tue, 10 Jan 2012 15:31:12 +0100, Jeff MAURY jeffma...@jeffmaury.com wrote: Works fine with 2 of my Tycho builds, maven-gwt-plugin and hudson-the-definitive-guide Jeff On Tue, Jan 10, 2012 at 2:13 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Works fine here. Regards Mirko On Tue, Jan 10, 2012 at 01:21, Stephen Connolly stephen.alan.conno...@gmail.com wrote: None here On 9 January 2012 23:44, Brett Porter br...@apache.org wrote: No issues here. On 06/01/2012, at 7:52 AM, Olivier Lamy wrote: Hello, Apache Maven 3.0.4-RC5 has been staged for testing purpose. This is a preview (and not an official supported version) of the coming 3.0.4 official release. The repository is available here: https://repository.apache.org/content/repositories/maven-017/ For convenience, binaries have been copied here: http://people.apache.org/~olamy/maven/3.0.4-RC5/ Changelog is available here: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=17215styleName=TextprojectId=10500Create=Create Since previous RC following changes have been added: * [MNG-5224] - REGRESSION: Injected Settings in a Mojo are missing the profiles from settings.xml * [MNG-5225] - The default version of the maven-site-plugin as defined in the site-lifecycle must be 3.x The review period will end on 16 Jan (see http://s.apache.org/REVIEW-END-MVN-3.0.4-RC5) Feel free to report any regressions in http://jira.codehaus.org/browse/MNG Have Fun! -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - 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 -- 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: [PROPOSAL] Reporting plugins should require Maven 2.2.1
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=285802page=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-170http://jira.codehaus .org/browse/MCHECKSTYLE-170 -Robert [1] http://maven.apache.org/**plugins/maven-shade-plugin/** examples/class-relocation.htmlhttp://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.**orgdev-unsubscr...@maven.apac he.org For additional commands, e-mail: dev-h...@maven.apache.org --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscribe@maven.apache .org For additional commands, e-mail: dev-h...@maven.apache.org --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-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: [PROPOSAL] Reporting plugins should require Maven 2.2.1
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=285802page=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-170http://jira.codehaus .org/browse/MCHECKSTYLE-170 -Robert [1] http://maven.apache.org/**plugins/maven-shade-plugin/** examples/class-relocation.htmlhttp://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.**orgdev-unsubscr...@maven.apac he.org For additional commands, e-mail: dev-h...@maven.apache.org --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscribe@maven.apache .org For additional commands, e-mail: dev-h...@maven.apache.org --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--** - To unsubscribe, e-mail:
[site] site.xml head/footer inheritance
Hi all guys, I am having troubles with the skin (lst check before re-proposing the skins releases) and while trying to apply fluido on Apache Commons I noticed that, attaching a site.xml descriptor to a parent, while the body.head element is inherited from cildren, body.footer is not. Did I miss something or this is the right behavior? Is there something to set or I have to provide an additional feature to the skin? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PROPOSAL] Reporting plugins should require Maven 2.2.1
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=285802page=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-170http://jira.codehaus .org/browse/MCHECKSTYLE-170 -Robert [1] http://maven.apache.org/**plugins/maven-shade-plugin/** examples/class-relocation.htmlhttp://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.**orgdev-unsubscr...@maven.apac he.org For additional commands, e-mail: dev-h...@maven.apache.org --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscribe@maven.apache .org For additional commands, e-mail: dev-h...@maven.apache.org --**--** - To unsubscribe, e-mail:
Re: [PROPOSAL] Reporting plugins should require Maven 2.2.1
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=285802page=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-170http://jira.codehaus .org/browse/MCHECKSTYLE-170 -Robert [1] http://maven.apache.org/**plugins/maven-shade-plugin/** examples/class-relocation.htmlhttp://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
Plugin development question
I am developing a Maven 2.2.1 plugin that will leverage JAR file(s) that vary depending on the target runtime system. These two examples describe the logic. 1) When the Maven plugin executes on a Linux box, it is going to fork off a Java application with a CLASSPATH that includes: a.jar and b.jar. 2) When the Maven plugin executes on a Windows box, it is going to fork off a Java application with a CLASSPATH that includes: x.jar and y.jar. The JAR files (i.e. a.jar, b.jar, x.jar, and y.jar) are private to the Maven plugin and not exposed to the Maven projects that use the plugin. I am trying to decide what is the best way to get the Maven plugin to access the JAR files (i.e. a.jar, b.jar, x.jar, and y.jar). Here are the options I am considering: 1) Add those JAR files as resources of the Maven plugin. 2) Add those JAR files to the Nexus repository and the Maven plugin downloads the JAR files via their GAV. 3) Add those JAR files to the Nexus repository and make all JAR files as dependencies on my plugin. The plugin will build up the CLASSPATH by parsing thru its dependencies. I do not like option 1), because I actually have multiple Maven plugins that are going to need to leverage the exact same functionality; and I do not want to store the same JAR files as resources of multiple plugins. I do not like option 2), because I am not sure of the best way to do this. I think that option 3) is probably the best solution, but in a way, I think option 2 might be a little cleaner. Q. Has anyone implemented option 2)? If so, could you provide some insight on how to do that? Thanks in advance, Bob *** *** This message contains information which may be confidential and privileged. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message.
Re: [VOTE] Release Maven EAR Plugin version 2.7
While fixing MEAR-60 is something very good, I am a bit worried about the lack of tests. There's only one IT. Other than that, looks good except a few things I've seen in recent commits but I have contacted 'rfscholte' to get some feedback. My +1 Thanks Dennis! S. On Thu, Jan 12, 2012 at 11:40 PM, Dennis Lundberg denn...@apache.orgwrote: Hi, We solved 4 issues, including [MEAR-60] Improve support for skinny war files which has 50 votes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11132styleName=Htmlversion=17293 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11132status=1 Staging repo: https://repository.apache.org/content/repositories/maven-060/ Staging site: http://maven.apache.org/plugins/maven-ear-plugin-2.7/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Maven EAR Plugin version 2.7
Hi, The vote has passed with the following result : +1 (binding): Olivier Lamy, Dennis Lundberg, Hervé Boutemy, Stephane Nicoll I will promote the artifacts to the central repo. On 2012-01-12 23:40, Dennis Lundberg wrote: Hi, We solved 4 issues, including [MEAR-60] Improve support for skinny war files which has 50 votes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11132styleName=Htmlversion=17293 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11132status=1 Staging repo: https://repository.apache.org/content/repositories/maven-060/ Staging site: http://maven.apache.org/plugins/maven-ear-plugin-2.7/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Error fetching link when running Javadoc Report, but can't find link
Hi When looking through the build log for the EAR Plugin release, I noticed a couple of errors like this one: --- [INFO] Generating JavaDocs report--- Maven Javadoc Plugin 2.8 [ERROR] Error fetching link: http://xmlunit.sourceforge.net/apidocs/package-list. Ignored it. [INFO] Loading source files for package org.apache.maven.plugin.ear... Loading source files for package org.apache.maven.plugin.ear.output... Loading source files for package org.apache.maven.plugin.ear.util... ... It seems that the Javadocs have moved, So I thought I'd fix the link. But I'm unable to find any reference to the above URL in the POM inheritance chain. Does anyone know where it could be? I used Maven 2.2.1 for the release, if that matters. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Intention to release maven-javadoc-plugin 2.8.1
I'm eager to get a release that has some of the fixes already on trunk, particularly those related to aggregating javadocs using dependencies. Does anyone have any objection to me calling a vote to release 2.8.1 with the seven closed issues that are currently assigned to it? The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11138version=17354 If not, I'll probably stage it and call the vote tomorrow afternoon. Thanks! -john -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Intention to release maven-javadoc-plugin 2.8.1
I would love for those changes to go out.. On 12-01-16 12:42 PM, John Casey wrote: I'm eager to get a release that has some of the fixes already on trunk, particularly those related to aggregating javadocs using dependencies. Does anyone have any objection to me calling a vote to release 2.8.1 with the seven closed issues that are currently assigned to it? The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11138version=17354 If not, I'll probably stage it and call the vote tomorrow afternoon. Thanks! -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Error fetching link when running Javadoc Report, but can't find link
Hi Dennis, Check the org.apache.maven.plugin.javadoc.AbstractJavadocMojo.getJavadocLink(MavenProject) It will build a javadoc link relative to the project URL as described in the pom of the dependency. -Robert On Mon, 16 Jan 2012 21:27:07 +0100, Dennis Lundberg denn...@apache.org wrote: http://xmlunit.sourceforge.net/apidocs/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven EAR Plugin 2.7 Released
The Maven team is pleased to announce the release of the Maven EAR Plugin, version 2.7 The most noteworthy in this release is the support for skinny WAR files. It is one of the most voted on issues in our JIRA with 50 votes. We would love to hear your feedback on this new feature. The plugin generates a J2EE Enterprise Archive (EAR) file. http://maven.apache.org/plugins/maven-ear-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId version2.7/version /plugin Release Notes - Maven EAR Plugin - Version 2.7 Improvement * [MEAR-60] Improve support for skinny WAR files New Feature * [MEAR-87] Allow exclusion of artifacts when building the ear file. Task * [MEAR-140] HTML Anchors on page EAR Modules defect * [MEAR-48] Remove the deprecated resourcesDir parameter Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Intention to release maven-javadoc-plugin 2.8.1
Sounds good On Monday, January 16, 2012, John Casey jdca...@commonjava.org wrote: I'm eager to get a release that has some of the fixes already on trunk, particularly those related to aggregating javadocs using dependencies. Does anyone have any objection to me calling a vote to release 2.8.1 with the seven closed issues that are currently assigned to it? The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11138version=17354 If not, I'll probably stage it and call the vote tomorrow afternoon. Thanks! -john -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
