Re: [VOTE] release maven-shade-plugin version 2.0
On Sun, Sep 2, 2012 at 4:22 PM, Mark Struberg strub...@yahoo.de wrote: This opens up another can of worms: how to deal with plugins which cannot be made maven2 compatible anymore but we like to implement a new feature? How long do we like to support maven2 at all? Will we create a branch for those plugins? The principle has to be that we can't force volunteers to volunteer, but we can make it easier. So, while we're wandering from the [VOTE], I'd propose these policies: 1: No 'gratuitous' introduction of M3 requirements. There's been plenty of email about this. 2: Make a branch for M2 releases before making the first M3 release. If someone has the itch, they can then port fixes and make releases on it without having to go spelunking to find the right rev to branch from. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Sunday, September 2, 2012 10:17 PM Subject: Re: [VOTE] release maven-shade-plugin version 2.0 Now we have a different problem. According to [1], the version to require Maven 3 was supposed to be 3.0, leaving 2.0 for a merely incompatible release that still worked with Maven 2.2. Folks, what's the story? Do I need to blow this up and try again as 3.0? Will someone fix what Hervé points to? [1] http://jira.codehaus.org/browse/MSHADE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel On Sun, Sep 2, 2012 at 11:38 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Sorry, I'm -0 about this: the plugin requires Maven 3 but uses an old dependency-tree which is not really Maven 3 compatible I updated the dependency in r1379995 Notice I manually removed extra directories in staging site Regards, Hervé Le vendredi 31 août 2012 18:00:45 Benson Margulies a écrit : We solved 4 issues: ** Bug * [MSHADE-103] - maven-shade-plugin does not resolve from user-defined repositories * [MSHADE-124] - Need better plan for getting dependency-reduced-pom.xml out of basedir * [MSHADE-130] - Mark mojo as threadSafe for parallel builds ** New Feature * [MSHADE-112] - New property to enable shading the java text inside the sources artifact (not just shading the java source file locations) There are still plenty more fish in this sea. Stating repo: https://repository.apache.org/content/repositories/maven-026/ https://repository.apache.org/content/repositories/maven-026/org/apache/mave n/plugins/maven-shade-plugin/2.0/maven-shade-plugin-2.0-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-2.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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] release maven-shade-plugin version 2.0
On Sun, Sep 2, 2012 at 5:12 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 2 septembre 2012 16:17:33 Benson Margulies a écrit : Now we have a different problem. According to [1], the version to require Maven 3 was supposed to be 3.0, leaving 2.0 for a merely incompatible release that still worked with Maven 2.2. Folks, what's the story? Do I need to blow this up and try again as 3.0? I don't see any difference naming this release 2.0 or 3.0. 2.0 is fine IMHO without jumping to 3.0, Jira comment should simply be added for 2.0, since MSHADE-103 seems to require the dependency (according to svn blame on pom.xml) Will someone fix what Hervé points to? It is already fixed, I fixed it in r1379995 (updated the dependency) Would you prefer if I respun the release? Regards, Hervé [1] http://jira.codehaus.org/browse/MSHADE#selectedTab=com.atlassian.jira.plugi n.system.project%3Aversions-panel On Sun, Sep 2, 2012 at 11:38 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Sorry, I'm -0 about this: the plugin requires Maven 3 but uses an old dependency-tree which is not really Maven 3 compatible I updated the dependency in r1379995 Notice I manually removed extra directories in staging site Regards, Hervé Le vendredi 31 août 2012 18:00:45 Benson Margulies a écrit : We solved 4 issues: ** Bug * [MSHADE-103] - maven-shade-plugin does not resolve from user-defined repositories * [MSHADE-124] - Need better plan for getting dependency-reduced-pom.xml out of basedir * [MSHADE-130] - Mark mojo as threadSafe for parallel builds ** New Feature * [MSHADE-112] - New property to enable shading the java text inside the sources artifact (not just shading the java source file locations) There are still plenty more fish in this sea. Stating repo: https://repository.apache.org/content/repositories/maven-026/ https://repository.apache.org/content/repositories/maven-026/org/apache/m ave n/plugins/maven-shade-plugin/2.0/maven-shade-plugin-2.0-source-release.z ip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-2.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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] release maven-shade-plugin version 2.0
OK, please consider this VOTE cancelled and I'll make a new one presently. On Sun, Sep 2, 2012 at 5:52 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 2 septembre 2012 17:22:20 Benson Margulies a écrit : Would you prefer if I respun the release? yes, I think this would be sufficient - 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] release maven-shade-plugin version 2.0
Hervé ~/asf/mvn/plugins/maven-shade-plugin/ /opt/apache-maven-3.0.4/bin/mvn release:prepare -Psigned_release [INFO] Scanning for projects... [ERROR] The build could not read 1 project - [Help 1] [ERROR] [ERROR] The project org.apache.maven.plugins:maven-shade-plugin:2.1-SNAPSHOT (/Users/benson/asf/mvn/plugins/maven-shade-plugin/pom.xml) has 1 error [ERROR] 'dependencies.dependency.version' for org.codehaus.plexus:plexus-component-annotations:jar is missing. @ line 140, column 17 On Sun, Sep 2, 2012 at 6:47 PM, Benson Margulies bimargul...@gmail.com wrote: OK, please consider this VOTE cancelled and I'll make a new one presently. On Sun, Sep 2, 2012 at 5:52 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 2 septembre 2012 17:22:20 Benson Margulies a écrit : Would you prefer if I respun the release? yes, I think this would be sufficient - 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
[VOTE] Release maven-shade-plugin 2.0 -- attempt 2
We solved 4 issues: ** Bug * [MSHADE-103] - maven-shade-plugin does not resolve from user-defined repositories * [MSHADE-124] - Need better plan for getting dependency-reduced-pom.xml out of basedir * [MSHADE-130] - Mark mojo as threadSafe for parallel builds ** New Feature * [MSHADE-112] - New property to enable shading the java text inside the sources artifact (not just shading the java source file locations) There are still plenty more fish in this sea. Stating repo: https://repository.apache.org/content/repositories/maven-028/ https://repository.apache.org/content/repositories/maven-028/org/apache/maven/plugins/maven-shade-plugin/2.0/maven-shade-plugin-2.0-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-2.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] release maven-shade-plugin version 2.0
I'm willing to do the branch homework once the dust settles. On Sun, Sep 2, 2012 at 7:30 PM, Chris Graham chrisgw...@gmail.com wrote: +1 for a branch. Sent from my iPhone On 03/09/2012, at 6:22 AM, Mark Struberg strub...@yahoo.de wrote: This opens up another can of worms: how to deal with plugins which cannot be made maven2 compatible anymore but we like to implement a new feature? How long do we like to support maven2 at all? Will we create a branch for those plugins? LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Sunday, September 2, 2012 10:17 PM Subject: Re: [VOTE] release maven-shade-plugin version 2.0 Now we have a different problem. According to [1], the version to require Maven 3 was supposed to be 3.0, leaving 2.0 for a merely incompatible release that still worked with Maven 2.2. Folks, what's the story? Do I need to blow this up and try again as 3.0? Will someone fix what Hervé points to? [1] http://jira.codehaus.org/browse/MSHADE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel On Sun, Sep 2, 2012 at 11:38 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Sorry, I'm -0 about this: the plugin requires Maven 3 but uses an old dependency-tree which is not really Maven 3 compatible I updated the dependency in r1379995 Notice I manually removed extra directories in staging site Regards, Hervé Le vendredi 31 août 2012 18:00:45 Benson Margulies a écrit : We solved 4 issues: ** Bug * [MSHADE-103] - maven-shade-plugin does not resolve from user-defined repositories * [MSHADE-124] - Need better plan for getting dependency-reduced-pom.xml out of basedir * [MSHADE-130] - Mark mojo as threadSafe for parallel builds ** New Feature * [MSHADE-112] - New property to enable shading the java text inside the sources artifact (not just shading the java source file locations) There are still plenty more fish in this sea. Stating repo: https://repository.apache.org/content/repositories/maven-026/ https://repository.apache.org/content/repositories/maven-026/org/apache/mave n/plugins/maven-shade-plugin/2.0/maven-shade-plugin-2.0-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-2.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Started release 1.7.2 of maven-shade-plugin, but ...
I cannot currently get to maven.apache.org to look at the cheat-sheet and remember all the release procedure steps. So it's out there on repository.apache.org, and I'll finish the job as soon as I can. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Shade Plugin Version 1.7.2
We solved 2 issues: ** Bug * [MSHADE-124] - Need better plan for getting dependency-reduced-pom.xml out of basedir * [MSHADE-130] - Mark mojo as threadSafe for parallel builds There are still plenty more fish in this sea. Stating repo: https://repository.apache.org/content/repositories/maven-025/ https://repository.apache.org/content/repositories/maven-025/org/apache/maven/plugins/maven-shade-plugin/1.7.2/maven-shade-plugin-1.7.2-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-1.7.2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Shade Plugin Version 1.7.2
On Fri, Aug 31, 2012 at 1:44 PM, Olivier Lamy ol...@apache.org wrote: You tag from trunk. AFAIK there are other issues to include (marked closed for 2.0: MSHADE-103 and MSHADE-112) Some weeks ago, we agree to bump version to 2.0 due to a non backward compatible change (see http://markmail.org/message/ywiw2mak7ltgo3qs ) I did tag from the trunk, I used the usual procedure. However, this version # thing went right past me, I apologize. I'll flush the staged release and do this again as 2.0. 2012/8/31 Benson Margulies bimargul...@gmail.com: We solved 2 issues: ** Bug * [MSHADE-124] - Need better plan for getting dependency-reduced-pom.xml out of basedir * [MSHADE-130] - Mark mojo as threadSafe for parallel builds There are still plenty more fish in this sea. Stating repo: https://repository.apache.org/content/repositories/maven-025/ https://repository.apache.org/content/repositories/maven-025/org/apache/maven/plugins/maven-shade-plugin/1.7.2/maven-shade-plugin-1.7.2-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-1.7.2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Shade Plugin Version 1.7.2
This vote is cancelled due to my being confused. Stand by for a 2.0. On Fri, Aug 31, 2012 at 1:25 PM, Benson Margulies bimargul...@gmail.com wrote: We solved 2 issues: ** Bug * [MSHADE-124] - Need better plan for getting dependency-reduced-pom.xml out of basedir * [MSHADE-130] - Mark mojo as threadSafe for parallel builds There are still plenty more fish in this sea. Stating repo: https://repository.apache.org/content/repositories/maven-025/ https://repository.apache.org/content/repositories/maven-025/org/apache/maven/plugins/maven-shade-plugin/1.7.2/maven-shade-plugin-1.7.2-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-1.7.2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Is it, in fact, time for maven-shade-plugin 2.0?
OK, now that I've cleaned up my previous mistake, I'll ask: is it a good time to actually do the 2.0 release? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] release maven-shade-plugin version 2.0
We solved 4 issues: ** Bug * [MSHADE-103] - maven-shade-plugin does not resolve from user-defined repositories * [MSHADE-124] - Need better plan for getting dependency-reduced-pom.xml out of basedir * [MSHADE-130] - Mark mojo as threadSafe for parallel builds ** New Feature * [MSHADE-112] - New property to enable shading the java text inside the sources artifact (not just shading the java source file locations) There are still plenty more fish in this sea. Stating repo: https://repository.apache.org/content/repositories/maven-026/ https://repository.apache.org/content/repositories/maven-026/org/apache/maven/plugins/maven-shade-plugin/2.0/maven-shade-plugin-2.0-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-2.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: improving incremental builds
On Mon, Aug 27, 2012 at 8:40 AM, Mark Struberg strub...@yahoo.de wrote: We might implement this by storing the list of all activated profiles + all resolved environment properties in a file in target/ somewhere. That would be part of a.) in my previous mail to Romain. How about the situation with shade? Build 1 runs shade and it replaces the primary build artifact with a shaded one. Build 2 sees that nothing has changed, but shade doesn't know, and it reshades, eating its own output with a ton of messages. Can I fix this in shade with current technologies? LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Monday, August 27, 2012 12:24 PM Subject: Re: improving incremental builds +0 for auto detecting changed scenarios. If someone changes a profile or the whole pom, then I'd expect he invokes a clean manually. We have to document this expectation of course. What do others think of this? I'm thinking it would be awesome (but maybe difficult) if plugins could determine if its configuration has changed, and then handle this automatically. If there are to many cases where a manual clean build is required, I believe people will continue to do mvn clean install (which I see all the time with developers), which I think is what we try to get away from. /Anders LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Monday, August 27, 2012 9:57 AM Subject: Re: improving incremental builds I already started tweaking the m-compiler-plugin and found quite scary issues. There is e.g. MCOMPILER-21 (open since 2005) which prevents incremental build and would kick in in your scenario. This is interesting. I've looked a bit at Mojo's JAXB plugin in the context of detecting stale generated files (i.e. need to re-generate) and it's similar to this. It would extremely nice if there would be a common framework for handling incremental builds. In addition to what's been mentioned in the jira (I just browsed it quickly), we have cases when includes/excludes change, the sourceDir changes, etc which should trigger cleanup and re-compilation. /Anders I talked about 2 scenarios a.) all phases = package, e.g. mvn verify, mvn install, ... Here we have an artifact on the disc and could test for the md5 of them, right? b.) all phases package. This is e.g. mvn compile or mvn test. In that case we don't produce a jar/war/ear/... artifact but only get the files on the disk linked in MavenProject#getProjectArtifacts()... file(). This is the case where the maven-compiler-plugin kicks in. I'm currently in the process of rewriting big parts of it, mainly I introduced b.1 a check for project.artifacts/project.testArtifacts .file() is a local file path .isDirectory() and has files which are newer (actually =) than the buildStarted timestamp. b.2 check whether there are any *.java (sourceincludes) files which are newer than their class files. In both cases I now force a FULL recompile of the module! Compiling only parts produced classes which are actually broken! My approach is the following: compiling a bit too much is better than missing some files which need compilation. Because the later is exactly the reason why noone uses mvn compile but always do a mvn clean compile nowadays. If mvn compile is reliable, then we will end up being much faster than an unconditional full compile on the whole project! LieGrue, strub PS: We need to move all our plugins which still use the plugin-testing-harness to the maven-invoker-plugin as the test-harness is broken with sisu. (sisu changed the 'container' field from plexus original: protected to 'private') PPS: how do we maintain the plexus-compiler-utils stuff? This contains some weirdo bugs which should get fixed... - Original Message - From: Olivier Lamy ol...@apache.org To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Monday, August 27, 2012 9:13 AM Subject: Re: improving incremental builds Hi, Sounds good idea trying to improve that. My question: on what is based the md5 calculation ? If people don't use 'install' but only 'test' (perso I use that to avoid too much io with jar creation etc..), so in such case we cannot do md5 calculation on the produced artifact. 2012/8/26 Mark Struberg strub...@yahoo.de: Hi David! So your idea is to find the list of changed modules and then build that list with -amd? Yes, kind of. At the moment mvn -amd builds the dependents of the _current_ module. If you use my example and change BeanA.java, then run mvn -amd from the root module you will see
Shade DRP location
I've been thinking about my abortive attempt to deal with multiple builds colliding over the dependency-reduced-pom.xml. My attempt was to move the thing into 'target', but that blew up relative pathnames. Here's another plan: give the thing a uuid-based name, instead. Can anyone think of a problem with that? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: improving incremental builds
On Mon, Aug 27, 2012 at 12:07 PM, Mark Struberg strub...@yahoo.de wrote: build1 and build 2 are different modules or different mvn invocations with some time inbetween? Of course we will need to test all plugins to behave incremental like! Means the maven-shade-plugin should check itself whether it needs shading or not at all. Two builds, separated in time, of exactly the same module. The problem here is that the jar plugin has already decided not to rebuild the jar by the time the shade plugin gets there, and I have no idea how to make the shade plugin play along. But the worst thing happening would be that we compile too much. Thats still better than a full mvn clean install :) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Monday, August 27, 2012 5:07 PM Subject: Re: improving incremental builds On Mon, Aug 27, 2012 at 8:40 AM, Mark Struberg strub...@yahoo.de wrote: We might implement this by storing the list of all activated profiles + all resolved environment properties in a file in target/ somewhere. That would be part of a.) in my previous mail to Romain. How about the situation with shade? Build 1 runs shade and it replaces the primary build artifact with a shaded one. Build 2 sees that nothing has changed, but shade doesn't know, and it reshades, eating its own output with a ton of messages. Can I fix this in shade with current technologies? LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Monday, August 27, 2012 12:24 PM Subject: Re: improving incremental builds +0 for auto detecting changed scenarios. If someone changes a profile or the whole pom, then I'd expect he invokes a clean manually. We have to document this expectation of course. What do others think of this? I'm thinking it would be awesome (but maybe difficult) if plugins could determine if its configuration has changed, and then handle this automatically. If there are to many cases where a manual clean build is required, I believe people will continue to do mvn clean install (which I see all the time with developers), which I think is what we try to get away from. /Anders LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Monday, August 27, 2012 9:57 AM Subject: Re: improving incremental builds I already started tweaking the m-compiler-plugin and found quite scary issues. There is e.g. MCOMPILER-21 (open since 2005) which prevents incremental build and would kick in in your scenario. This is interesting. I've looked a bit at Mojo's JAXB plugin in the context of detecting stale generated files (i.e. need to re-generate) and it's similar to this. It would extremely nice if there would be a common framework for handling incremental builds. In addition to what's been mentioned in the jira (I just browsed it quickly), we have cases when includes/excludes change, the sourceDir changes, etc which should trigger cleanup and re-compilation. /Anders I talked about 2 scenarios a.) all phases = package, e.g. mvn verify, mvn install, ... Here we have an artifact on the disc and could test for the md5 of them, right? b.) all phases package. This is e.g. mvn compile or mvn test. In that case we don't produce a jar/war/ear/... artifact but only get the files on the disk linked in MavenProject#getProjectArtifacts()... file(). This is the case where the maven-compiler-plugin kicks in. I'm currently in the process of rewriting big parts of it, mainly I introduced b.1 a check for project.artifacts/project.testArtifacts .file() is a local file path .isDirectory() and has files which are newer (actually =) than the buildStarted timestamp. b.2 check whether there are any *.java (sourceincludes) files which are newer than their class files. In both cases I now force a FULL recompile of the module! Compiling only parts produced classes which are actually broken! My approach is the following: compiling a bit too much is better than missing some files which need compilation. Because the later is exactly the reason why noone uses mvn compile but always do a mvn clean compile nowadays. If mvn compile is reliable, then we will end up being much faster than an unconditional full compile on the whole project! LieGrue, strub PS: We need to move all our plugins which still use the plugin-testing-harness to the maven-invoker-plugin as the test-harness is broken with sisu. (sisu changed the 'container' field from
Re: improving incremental builds
On Mon, Aug 27, 2012 at 1:27 PM, Martin Gainty mgai...@hotmail.com wrote: Benson any chance of *forcing* the second iteration to re-jar with forceCreationtrue/forceCreation http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#forceCreation Yes, in my personal projects. That does not solve the real problem, in my opinion, which is that somehow the core should allow these plugins to communicate and 'just get it right'. It's complex -- changes to dependencies that require re-shading would need to trigger re-jarring. Martin __ ..place long-winded disclaimer here.. Date: Mon, 27 Aug 2012 13:09:59 -0400 Subject: Re: improving incremental builds From: bimargul...@gmail.com To: dev@maven.apache.org; strub...@yahoo.de On Mon, Aug 27, 2012 at 12:07 PM, Mark Struberg strub...@yahoo.de wrote: build1 and build 2 are different modules or different mvn invocations with some time inbetween? Of course we will need to test all plugins to behave incremental like! Means the maven-shade-plugin should check itself whether it needs shading or not at all. Two builds, separated in time, of exactly the same module. The problem here is that the jar plugin has already decided not to rebuild the jar by the time the shade plugin gets there, and I have no idea how to make the shade plugin play along. But the worst thing happening would be that we compile too much. Thats still better than a full mvn clean install :) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Monday, August 27, 2012 5:07 PM Subject: Re: improving incremental builds On Mon, Aug 27, 2012 at 8:40 AM, Mark Struberg strub...@yahoo.de wrote: We might implement this by storing the list of all activated profiles + all resolved environment properties in a file in target/ somewhere. That would be part of a.) in my previous mail to Romain. How about the situation with shade? Build 1 runs shade and it replaces the primary build artifact with a shaded one. Build 2 sees that nothing has changed, but shade doesn't know, and it reshades, eating its own output with a ton of messages. Can I fix this in shade with current technologies? LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Monday, August 27, 2012 12:24 PM Subject: Re: improving incremental builds +0 for auto detecting changed scenarios. If someone changes a profile or the whole pom, then I'd expect he invokes a clean manually. We have to document this expectation of course. What do others think of this? I'm thinking it would be awesome (but maybe difficult) if plugins could determine if its configuration has changed, and then handle this automatically. If there are to many cases where a manual clean build is required, I believe people will continue to do mvn clean install (which I see all the time with developers), which I think is what we try to get away from. /Anders LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Monday, August 27, 2012 9:57 AM Subject: Re: improving incremental builds I already started tweaking the m-compiler-plugin and found quite scary issues. There is e.g. MCOMPILER-21 (open since 2005) which prevents incremental build and would kick in in your scenario. This is interesting. I've looked a bit at Mojo's JAXB plugin in the context of detecting stale generated files (i.e. need to re-generate) and it's similar to this. It would extremely nice if there would be a common framework for handling incremental builds. In addition to what's been mentioned in the jira (I just browsed it quickly), we have cases when includes/excludes change, the sourceDir changes, etc which should trigger cleanup and re-compilation. /Anders I talked about 2 scenarios a.) all phases = package, e.g. mvn verify, mvn install, ... Here we have an artifact on the disc and could test for the md5 of them, right? b.) all phases package. This is e.g. mvn compile or mvn test. In that case we don't produce a jar/war/ear/... artifact but only get the files on the disk linked in MavenProject#getProjectArtifacts()... file(). This is the case where the maven-compiler-plugin kicks in. I'm currently in the process of rewriting big parts of it, mainly I introduced b.1 a check for project.artifacts/project.testArtifacts .file() is a local file path
Re: improving incremental builds
Mark, I don't see how this helps. If the jar plugin hasn't rebuilt the jar, the shade plugin can't rebuild the jar, even if, for other reasons, it needs to. It has knowledge that the jar plugin lacks. On Mon, Aug 27, 2012 at 4:04 PM, Mark Struberg strub...@yahoo.de wrote: the shade plugin would just need to store a local status file with the md5 of the created result. Or add the info to the manifest as you proposed. The main point is that this should be up to the maven-shade-plugin, as it is the only one who knows when to repeat this step. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Monday, August 27, 2012 9:53 PM Subject: Re: improving incremental builds The issue (for benson) is when the shade plugin modifies after the class files have changed... the jar plugin will currently skip recreating the jar, and he has no way of knowing if the jar file has been shaded or not the solution is to have the manifest.mf include an entry that indicates created by shade, so that shade can safely skip On 27 August 2012 19:39, Mark Struberg strub...@yahoo.de wrote: Not sure if I get the problem. The timestamp of the input files is still than the timestamp of the jar file. Regardless if it later got modified by the shade-plugin or not. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Monday, August 27, 2012 8:11 PM Subject: Re: improving incremental builds On 27 August 2012 19:10, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 27 August 2012 18:09, Benson Margulies bimargul...@gmail.com wrote: On Mon, Aug 27, 2012 at 12:07 PM, Mark Struberg strub...@yahoo.de wrote: build1 and build 2 are different modules or different mvn invocations with some time inbetween? Of course we will need to test all plugins to behave incremental like! Means the maven-shade-plugin should check itself whether it needs shading or not at all. Two builds, separated in time, of exactly the same module. The problem here is that the jar plugin has already decided not to rebuild the jar by the time the shade plugin gets there, and I have no idea how to make the shade plugin play along. Any chance we can get the jar plugin to inspect some of the artifacts that it generates into the jar to see if they are consistent with what the jar plugin produces... I'm looking at you META-INF/MANIFEST.MF I.O.W. if the Created-By: Apache Maven 3.0.4 (Maven JAR Plugin) is switched to Created-By: Apache Maven 3.0.4 (Maven Shade Plugin) Then the Maven JAR plugin can infer that the timestamp check is pointless, and force regen And people customizing that header can just live with the issues that creates. -Stephen But the worst thing happening would be that we compile too much. Thats still better than a full mvn clean install :) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Monday, August 27, 2012 5:07 PM Subject: Re: improving incremental builds On Mon, Aug 27, 2012 at 8:40 AM, Mark Struberg strub...@yahoo.de wrote: We might implement this by storing the list of all activated profiles + all resolved environment properties in a file in target/ somewhere. That would be part of a.) in my previous mail to Romain. How about the situation with shade? Build 1 runs shade and it replaces the primary build artifact with a shaded one. Build 2 sees that nothing has changed, but shade doesn't know, and it reshades, eating its own output with a ton of messages. Can I fix this in shade with current technologies? LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Monday, August 27, 2012 12:24 PM Subject: Re: improving incremental builds +0 for auto detecting changed scenarios. If someone changes a profile or the whole pom, then I'd expect he invokes a clean manually. We have to document this expectation of course. What do others think of this? I'm thinking it would be awesome (but maybe difficult) if plugins could determine if its configuration has changed, and then handle this automatically. If there are to many cases where a manual clean build is required, I believe people will continue to do mvn clean install (which I see all the time with developers), which I think is what we try to get away from. /Anders LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent
Re: improving incremental builds
On Mon, Aug 27, 2012 at 5:56 PM, Mark Struberg strub...@yahoo.de wrote: It's a chain. The maven-compiler-plugin sees that there are stale sources or changed dependencies and compiles the sources. The jar plugin sees that there are changed classes which have a newer timestamp than the jar file, so it creates the jar again. The maven-shade-plugin will see the md5 of the jar changed (or detect otherwise that this is not a shaded jar) and trigger the shading. Not good enough. Let me describe the failure mode. No sources have changed. So the compiler plugin doesn't recompile. So, no .class files have changed, so the jar plugin doesn't jar. However, a dependency *has* changed, so the shade plugin needs a clean input. But it doesn't have a clean input, since the only thing around is the jar it shaded last time around. The only fix I can see is if the shade plugin keeps around a copy of the original unshaded jar when it shades, and uses that to redo the shade when all of this happens. Of course, most of those plugins do not yet support this. But there is nothing stopping us from hacking that ;) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Monday, August 27, 2012 11:13 PM Subject: Re: improving incremental builds Mark, I don't see how this helps. If the jar plugin hasn't rebuilt the jar, the shade plugin can't rebuild the jar, even if, for other reasons, it needs to. It has knowledge that the jar plugin lacks. On Mon, Aug 27, 2012 at 4:04 PM, Mark Struberg strub...@yahoo.de wrote: the shade plugin would just need to store a local status file with the md5 of the created result. Or add the info to the manifest as you proposed. The main point is that this should be up to the maven-shade-plugin, as it is the only one who knows when to repeat this step. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Monday, August 27, 2012 9:53 PM Subject: Re: improving incremental builds The issue (for benson) is when the shade plugin modifies after the class files have changed... the jar plugin will currently skip recreating the jar, and he has no way of knowing if the jar file has been shaded or not the solution is to have the manifest.mf include an entry that indicates created by shade, so that shade can safely skip On 27 August 2012 19:39, Mark Struberg strub...@yahoo.de wrote: Not sure if I get the problem. The timestamp of the input files is still than the timestamp of the jar file. Regardless if it later got modified by the shade-plugin or not. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Monday, August 27, 2012 8:11 PM Subject: Re: improving incremental builds On 27 August 2012 19:10, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 27 August 2012 18:09, Benson Margulies bimargul...@gmail.com wrote: On Mon, Aug 27, 2012 at 12:07 PM, Mark Struberg strub...@yahoo.de wrote: build1 and build 2 are different modules or different mvn invocations with some time inbetween? Of course we will need to test all plugins to behave incremental like! Means the maven-shade-plugin should check itself whether it needs shading or not at all. Two builds, separated in time, of exactly the same module. The problem here is that the jar plugin has already decided not to rebuild the jar by the time the shade plugin gets there, and I have no idea how to make the shade plugin play along. Any chance we can get the jar plugin to inspect some of the artifacts that it generates into the jar to see if they are consistent with what the jar plugin produces... I'm looking at you META-INF/MANIFEST.MF I.O.W. if the Created-By: Apache Maven 3.0.4 (Maven JAR Plugin) is switched to Created-By: Apache Maven 3.0.4 (Maven Shade Plugin) Then the Maven JAR plugin can infer that the timestamp check is pointless, and force regen And people customizing that header can just live with the issues that creates. -Stephen But the worst thing happening would be that we compile too much. Thats still better than a full mvn clean install :) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Monday, August 27, 2012 5:07 PM Subject: Re: improving incremental builds On Mon, Aug 27, 2012 at 8:40 AM, Mark Struberg strub...@yahoo.de wrote: We might implement this by storing the list of all activated profiles + all resolved
The web site plugin in the sandbox
Hervé sent out a message about this, and I can't find it. I'm travelling today, but I can poke around tonight. My recollection was that I couldn't figure out how to write a working IT without a self-contained mocked scm to have it manipulate, but it's been a while. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Parent pom 22, Maven Plugins Parent pom 23, Maven Shared Components 18
+1. On Sun, Aug 12, 2012 at 3:39 PM, Mark Struberg strub...@yahoo.de wrote: looked at the diffs and they do look fine. +1 LieGrue, strub - Original Message - From: Olivier Lamy ol...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, August 10, 2012 3:52 PM Subject: [VOTE] Release Maven Parent pom 22, Maven Plugins Parent pom 23, Maven Shared Components 18 Hi, I'd like to release: * Maven Parent pom 22, diff from previous release: http://svn.apache.org/viewvc/maven/pom/tags/maven-parent-22/pom.xml?r1=HEADr2=1157980diff_format=h * Maven Plugins Parent pom 23, diff from previous release: http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-23/pom.xml?r1=HEADr2=1157988diff_format=h * Maven Shared Components 18: http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-18/pom.xml?r1=HEADr2=1158001diff_format=h Staging repository: https://repository.apache.org/content/repositories/maven-129/ Vote open for 72H. [+1] [0] [-1] Thanks -- 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] Relase Apache Parent Pom 11
Don't you want the new dependency plugin? On Sun, Aug 5, 2012 at 5:49 PM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Apache Parent 11. Staging repository is here: https://repository.apache.org/content/repositories/orgapacheapache-120/ Staged documentation: http://maven.apache.org/pom/asf-11/ Diff from previous release: http://svn.apache.org/viewvc/maven/pom/tags/apache-11/pom.xml?r1=HEADr2=1154610diff_format=h Vote open for 72H. [+1] [0] [-1] Thanks -- 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] Release Maven Surefire Plugin version 2.12.1
+1 binding. I don't see that issue as a blocker. On Wed, Aug 1, 2012 at 1:47 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I have updated the doc pages in question; http://maven.apache.org/plugins/maven-surefire-plugin-2.12.1/plugins/maven-surefire-plugin/featurematrix.html http://maven.apache.org/plugins/maven-surefire-plugin-2.12.1/plugins/maven-surefire-plugin/examples/single-test.html I also created https://jira.codehaus.org/browse/SUREFIRE-893, which I'll try to get fiexd for the next release. The vote will complete in less than 24 hours. @Milos; you're still registered with a -1 (onlist-dialogue (+ some offlist) has this release proceeding anyway) Kristian 2012/7/31 Milos Kleint mkle...@gmail.com: then update this page as well: http://maven.apache.org/plugins/maven-surefire-plugin-2.12.1/plugins/maven-surefire-plugin/examples/single-test.html On Mon, Jul 30, 2012 at 10:04 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: There is an integration test (TestMultipleMethodsIT) that runs the project located at SVN in https://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/junit48-multiple-methods https://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/junit44-multiple-methods This test passed using this command: mvn -Dtest=junit4.BasicTest#testSuccessOne+testFailOne,junit4.TestThree#testSuccessTwo -Dsurefire.version=2.12.1 test Is this a documentation problem or is there some other issue ? Please try to reproduce in terms of the existing IT projects if you can. As for TestNG, I do not believe this is supported (neither JUnit3). I will update the official feature matrix (http://maven.apache.org/plugins/maven-surefire-plugin-2.12.1/plugins/maven-surefire-plugin/featurematrix.html) and mark this as not supported for TestNG/JUnit3. I will redeploy the site sometime tomorrow. Since we traditionally do not cancel votes due to documentation changes, I'm not cancelling this vote until there's a clear proof of a bug. If necessary I'll extend the vote period so we're sure. Kristian mvn -Dsurefire.version=2.12.1 -Dtest=test.mavenproject2.AppNGTest#testMain,test.mavenproject2.AppNGTest#testMain2 test 2012/7/30 Milos Kleint mkle...@gmail.com: -1 surefire 1.12.1 + testng 6.5.2 or 6.7: mvn -Dtest=test.mavenproject2.AppNGTest#testMain,test.mavenproject2.AppNGTest#testMain2 test doesn't work (no tests run), even though running just 1 test method will succeed. surefire 1.12.1 + junit 4.10: mvn -Dtest=test.mavenproject1.AppTest#testMain2,test.mavenproject1.AppTest#testMain test doesn't work either, will run just one test, ignore the other. If I have 2 test classes each with 2 failing tests and attempt to execute all of them, then only one per class file is executed. the variants with 1 test method being executed work fine. variant with multiple test classes (not methods) does work in both testng and junit4. Milos On Sun, Jul 29, 2012 at 10:45 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Hi, This is a bugfix release. We solved a few issues: Bug [SUREFIRE-659] - Maven PDF plugin:showSuccess=false creates empty table causing error [SUREFIRE-825] - NPE in JUnit4TestChecker if org.junit.runner.RunWith class can't be loaded by testClassloader [SUREFIRE-827] - Surefire 2.12 cannot run a single test, regression from 2.11 [SUREFIRE-828] - testng test need a excludedGroups element to not fail [SUREFIRE-832] - JUnit categories only work when junit47 provider is explicitly set [SUREFIRE-836] - regression with surefire 2.12 plugin and SecurityManager [SUREFIRE-844] - test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11) [SUREFIRE-847] - surefire cannot run single testng test [SUREFIRE-858] - Running a single unit test in Windows [SUREFIRE-865] - surefire 2.12 with parallel=methods does not execute junit 4.7+ tests in parallel [SUREFIRE-869] - Parallel test execution on class level runs not all tests but some twice [SUREFIRE-871] - Output of forked tests with non-zero exit code not retained [SUREFIRE-877] - Surefire doesn't support mixed TestNG 6.5.x config parameter [SUREFIRE-879] - maven-surefire-report-plugin fails some times with ConcurrentModificationException when running parallel TestNG [SUREFIRE-880] - ObjectFactory no longer works with TestNG 6.5.2 [SUREFIRE-883] - Cannot run tests in parallel Improvement [SUREFIRE-745] - -Dtest supports multiple test classes but not multiple test methods [SUREFIRE-876] - surefire-junit47 does not work in an OSGi classloader environment [SUREFIRE-881] - use plugins annotations [SUREFIRE-889] - JUnit | supprot inheritance of test's categories/groups We unresolved 1 issue; which had to be reverted because it was the root cause of several of
Re: Are there any plans for a Maven Assembly plugin release in the near future?
I can organize this in a few days if no one beats me to it. On Tue, Jul 31, 2012 at 4:33 PM, Ryan Gardner ryeb...@gmail.com wrote: There are two issues fixed in maven assembly 2.4 and http://jira.codehaus.org/browse/MASSEMBLY-553 is one that is extremely useful - I'm not an apache committer / person of any consequence. Is there any chance that the maven assembly plugin can have the release process started sometime soon? If not, I can build a custom version that has those fixes in place and use that instead. Ryan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Snark on the users list
I don't see any problem with a clear statement that 'maven is a development tool for developers'. I agree that going past that to any of the recent attempts to encode RTFM or 'go find a buddy' into some sort of sentence on the web site is a loser, in spite of my attempt to craft one. On Mon, Jul 23, 2012 at 10:24 PM, Barrie Treloar baerr...@gmail.com wrote: On Tue, Jul 24, 2012 at 11:52 AM, Jesse Farinacci jie...@gmail.com wrote: Greetings, [del] I guess I don't think anyone that we'd like to tell STFU and RTFM will read any manual anyway. The people that will read the manual will be a bit put off, I suspect, by the harsh way we treat the unseasoned. Yes, exactly. So we don't get any benefit from having such language around. It would be far better to just get a really good FAQ and Cookbook (a la Sonatype's thing) where we can just respond with a single link and that will end the thread. In addition, linking to existing solutions will result in (minimal) search engine optimization for those sites via cross linking, etc, thereby promoting those FAQ/Recipes higher in searches. That's why I have this canned response: Please have a look at the freely available books at http://maven.apache.org/articles.html - 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: Snark on the users list
On Tue, Jul 24, 2012 at 5:05 PM, Barrie Treloar baerr...@gmail.com wrote: On Tue, Jul 24, 2012 at 10:26 PM, Benson Margulies bimargul...@gmail.com wrote: I don't see any problem with a clear statement that 'maven is a development tool for developers'. I agree that going past that to any of the recent attempts to encode RTFM or 'go find a buddy' into some sort of sentence on the web site is a loser, in spite of my attempt to craft one. Do we back out the my changes to guides/getting-started/maven-in-five-minutes.apt then? No, but I might try another edit to reconcile the various opinons. - 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: Surefire 2.12.1
I can do it On Jul 23, 2012, at 4:35 AM, Olivier Lamy ol...@apache.org wrote: Hi Same here. Cannot help before sunday. -- Olivier Le 22 juil. 2012 20:35, Kristian Rosenvold kristian.rosenv...@gmail.com a écrit : I'm ready to press release on this one as of r1364394, and jira is all set to go. Unfortunately I left all my gpg keys at home (i'm on vacation), so unless someone else wants to push it it's going to be another week. Kristian - 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: Snark on the users list
Rev 1364633 is a small contribution to more stuff to link to. On Sun, Jul 22, 2012 at 8:41 AM, Benson Margulies bimargul...@gmail.com wrote: Look, I know that we get lots of very provocatively clueless queries on the user list. However, I don't think that it's a good idea to be as acerbic as some of us have been lately. My advice is this: if you are out of patience with clueless email, just don't answer it. If you have a little patience, post a boilerplate email pointing to online resources. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Can't deploy the site?
running mvn site-deploy with 3.0.4 on the site hierarchy ... [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.1:jar (jar) on project maven-site: Error while creating archive. A zip file cannot include itself - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Surefire 2.12.1
Unfortunately, lots of the integration tests failed on my mac when I ran release:perform. I'll try again with a Linux VM. On Sun, Jul 22, 2012 at 2:34 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I'm ready to press release on this one as of r1364394, and jira is all set to go. Unfortunately I left all my gpg keys at home (i'm on vacation), so unless someone else wants to push it it's going to be another week. Kristian - 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: Surefire 2.12.1
I can't get through prepare either on Linux or MacOSX. On Mon, Jul 23, 2012 at 12:10 PM, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: I may have seen this happen; re-running release:perform does the trick. K Den 23. juli 2012 kl. 17:33 skrev Benson Margulies bimargul...@gmail.com: Unfortunately, lots of the integration tests failed on my mac when I ran release:perform. I'll try again with a Linux VM. On Sun, Jul 22, 2012 at 2:34 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I'm ready to press release on this one as of r1364394, and jira is all set to go. Unfortunately I left all my gpg keys at home (i'm on vacation), so unless someone else wants to push it it's going to be another week. Kristian - 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: Snark on the users list
On Mon, Jul 23, 2012 at 6:54 PM, Barrie Treloar baerr...@gmail.com wrote: On Tue, Jul 24, 2012 at 7:49 AM, Wayne Fay wayne...@gmail.com wrote: Rev 1364633 is a small contribution to more stuff to link to. Also on the Windows pre-reqs page, it might be nice to say something about antivirus software sometimes preventing Java from running properly, or Windows Firewall (and various other Firewalls) actively preventing Java.exe from reaching out to the Internet to download stuff which is a key part of Maven -- so that users will know to add exceptions to grant such actions. How about this: Maven is a command-line development tool intended for use by experienced software developers. As such, it does not come in a package with an installer, and all of the available documentation assumes that you are familiar with command-line tools. You have to be prepared to install and work with tools like this to use Maven. If you aren't comfortable with tools like this, but you need to use Maven for some reason, you will need to find assistance, and the Maven user community is not a great place to get it, since that community expects that users have this level of skill and experience. Done. Also added to the 5 min guide: Prerequisites You must have an understanding of how to install software on your computer. If you do not know how to do this, please ask someone at your office, school, etc or pay someone to explain this to you. The Maven mailing lists are not the best place to ask for this advice. I have only committed this and not redeployed the web site so that others can adjust the tone of the paragraph. I was reluctant to have a negative paragraph as the first thing to do in the 5 minutes guide, especially one that says don't contact the mailing list with these questions. Improvements welcome. p.s. I wonder if the people who are the audience for these changes actually read these pages? - 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: Snark on the users list
On Mon, Jul 23, 2012 at 8:58 PM, Jesse Farinacci jie...@gmail.com wrote: On Mon, Jul 23, 2012 at 8:40 PM, Benson Margulies bimargul...@gmail.com wrote: If you aren't comfortable with tools like this, but you need to use Maven for some reason, you will need to find assistance, and the Maven user community is not a great place to get it, since that community expects that users have this level of skill and experience. -1 ... this really is off putting. Oh, well, so much for that idea. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - 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
Snark on the users list
Look, I know that we get lots of very provocatively clueless queries on the user list. However, I don't think that it's a good idea to be as acerbic as some of us have been lately. My advice is this: if you are out of patience with clueless email, just don't answer it. If you have a little patience, post a boilerplate email pointing to online resources. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Snark on the users list
A number of people have contacted me off-list about this. I really didn't want to call anyone out on this topic. This is a mixed bag. Citing specific threads would make it concrete what I'm point at, but it would call people out. I'll respond to the off-list threads. I'll go this far; we've had (I think) two pretty help-vampirish people turn up recently with an awe-inspiring lack of the necessary minimal background in using Windows and Java to have any business trying to use Maven. Another aspect of the situation is that a few people are carrying a disproportionate amount of the load of dealing with the user list, and if some of the rest of us would step up more, that would be better. On Sun, Jul 22, 2012 at 10:06 AM, Martin Gainty mgai...@hotmail.com wrote: correct ..these posts are broadcast worldwide (and then stored as google links).. I am 3500 miles from Bensons location but i am fully capable of reading his emails! I agree the older and wiser maven committee members *should* set a good example so that other maven committers adhere to the higher Maven standardBUT this rule *should* apply for all apache committee members! if this rule is broken a corrective email such as this one should be sent to the committee member to adhere to the properly formatted response This would be a shot across the bow from the Maven Hague +1 Martin __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Sun, 22 Jul 2012 08:41:43 -0400 Subject: Snark on the users list From: bimargul...@gmail.com To: dev@maven.apache.org Look, I know that we get lots of very provocatively clueless queries on the user list. However, I don't think that it's a good idea to be as acerbic as some of us have been lately. My advice is this: if you are out of patience with clueless email, just don't answer it. If you have a little patience, post a boilerplate email pointing to online resources. - 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
https://jira.codehaus.org/browse/MPLUGIN-219
Hey: I'm about to commit a fix to this, which keeps the existing spelling with @Deprecated and adds the new spelling. I'll wait until tomorrow AM my time in case any of your Europeans really hate the idea. --benson - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE RESULT] Release maven-shade-plugin 1.7.1
This vote passes with four binding +1's: bimargulies, herve.boutemy, olamy, dkulp. I will promote. On Thu, Jun 28, 2012 at 6:31 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: +1 Hervé Le mercredi 27 juin 2012 07:53:44 Benson Margulies a écrit : Hi, We solved 1 issues: ** Bug * [MSHADE-123] - 1.7 Causes failures in other plugins make basedir point to the build dir There are still plenty of issues left in JIRA. Staging repo: https://repository.apache.org/content/repositories/maven-282/ https://repository.apache.org/content/repositories/maven-282/maven-shade-plu gin-1.7.1-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-1.7.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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
Order of execution of plugins
https://jira.codehaus.org/browse/MSHADE-126 seems, I think, to result from a Pretty Dumb Thing. I suspect that the problem is that the jar plugin has ended up in the packaging phase AFTER the shade plugin, due to the way that plugin management and plugin elements merge. Does this make any sense to anyone? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Order of execution of plugins
Cancel this thought. The jar plugin purports to run first. On Fri, Jun 29, 2012 at 9:12 AM, Benson Margulies bimargul...@gmail.com wrote: https://jira.codehaus.org/browse/MSHADE-126 seems, I think, to result from a Pretty Dumb Thing. I suspect that the problem is that the jar plugin has ended up in the packaging phase AFTER the shade plugin, due to the way that plugin management and plugin elements merge. Does this make any sense to anyone? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Order of execution of plugins
OK, now I understand this. The jar plugin will optimize out writing a jar in some cases. This is never a good idea is shade has produced the jar. But the jar plugin has no way, I can see, to notice this. So the jar plugin leaves the shaded jar and then shade explodes. I can see two possible approaches: 1) Write notes in both plugin's doc to explain what is going on. I will certainly add some doc to the jar plugin, since the existing explanation of the forceUpdate param is not helpful. 2) Make the jar plugin look for some sort of time that the shade plugin can leave lying about to indicate that the jar has been tampered with and must be rebuilt. Thoughts? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Order of execution of plugins
I like this. On Fri, Jun 29, 2012 at 9:48 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 3) add a shade:clean goal which removes the jar and let people bind that to prepare-package On 29 June 2012 14:28, Benson Margulies bimargul...@gmail.com wrote: OK, now I understand this. The jar plugin will optimize out writing a jar in some cases. This is never a good idea is shade has produced the jar. But the jar plugin has no way, I can see, to notice this. So the jar plugin leaves the shaded jar and then shade explodes. I can see two possible approaches: 1) Write notes in both plugin's doc to explain what is going on. I will certainly add some doc to the jar plugin, since the existing explanation of the forceUpdate param is not helpful. 2) Make the jar plugin look for some sort of time that the shade plugin can leave lying about to indicate that the jar has been tampered with and must be rebuilt. Thoughts? - 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: maven-plugin-plugin thinks there's no mojos when I use annotations
THanks. On Fri, Jun 29, 2012 at 8:04 PM, Tony Chemit che...@codelutin.com wrote: On Fri, 29 Jun 2012 19:58:53 -0400 Benson Margulies bimargul...@gmail.com wrote: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:3.0:helpmojo (generated-helpmojo) on project maven-shade-plugin: Error extracting plugin descriptor: 'No mojo definitions were found for plugin: org.apache.maven.plugins:maven-shade-plugin.' - [Help 1] even though I've got: @Mojo(name = shade, defaultPhase = LifecyclePhase.PACKAGE, threadSafe = false, requiresDependencyResolution = ResolutionScope.RUNTIME) on the class. Yes that's because the helpmojo is inovked at generate-sources phase, but descriptor is now invoked at process-classes (to process annotations). to avoid your problem just add in the maven-plugin-plugin this configuration : configuration skipErrorNoDescriptorsFoundtrue/skipErrorNoDescriptorsFound /configuration see http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - 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: MSHADE-123: call for help
On Wed, Jun 27, 2012 at 2:42 AM, Jörg Schaible
joerg.schai...@scalaris.com wrote:
Benson Margulies wrote:
Folks,
I've dug a hole (reported by) MSHADE-123 and I don't know what to do about
this.
I dug the hole via the changes to move the default location of the
dependency reduced pom from the project basedir to target. Having the
drp in the basedir led to chaos when multiple builds ran in parallel
(all set with distinct output directories).
MavenProject.java defines getBasedir() to be the containing dir of the
pom, period. So if the drp isn't in the base dir, anything that runs
after shade is going to get an unpleasant surprise if it tries to use
${basedir} for something.
One possibly mitigation would be to set the default for the drp back
to the basedir, so that only crazy people like me would move it
someplace else.
A bigger fix would be to change MavenProject.java to allow an explicit
setting of basedir to be someplace other than where the pom lives.
Then shade could set it to the original basedir.
Thoughts?
What about creating a copy of the project beneath target (or target/reduced)
instead? Similar to the action of the release plugin using target/checkout.
Well, any rel paths anywhere in the project that reach outside the
project would then fail, since I don't see how we'd catch them all.
That might be better than the alternatives.
Just an idea.
- Jörg
-
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
[VOTE] Release maven-shade-plugin 1.7.1
Hi, We solved 1 issues: ** Bug * [MSHADE-123] - 1.7 Causes failures in other plugins make basedir point to the build dir There are still plenty of issues left in JIRA. Staging repo: https://repository.apache.org/content/repositories/maven-282/ https://repository.apache.org/content/repositories/maven-282/maven-shade-plugin-1.7.1-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-1.7.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Shade plugin non backward compatible change
On Wed, Jun 27, 2012 at 7:39 AM, Olivier Lamy ol...@apache.org wrote: +1 fine for me OK, 1.7.1 staged and out for vote. 2012/6/27 Benson Margulies bimargul...@gmail.com: Here's my proposed plan. 1) I do something about MSHADE-123: move the default back to basedir. 2) I release 1.7.1. 3) You move the next version to 2.0 or 3.0, and fix MSHADE-112. 4) I apply the patch to MSHADE-103 that requires us to depend on Maven 3. 5) anyone who really wants a fix for Maven 2 after this branches. On Tue, Jun 26, 2012 at 4:56 PM, Olivier Lamy ol...@apache.org wrote: Hi, I don't know if you have a look @ MSHADE-112 Basically the goal is to be able to pass more and more parameters to the Shader. This need to change - void shade( SetFile jars, File uberJar, ListFilter filters, ListRelocator relocators, - ListResourceTransformer resourceTransformers ) + void shade( ShadeRequest shadeRequest ) throws IOException, MojoExecutionException; As it adding more parameters in the future tru ShadeRequest class will be more easy (and backward compatible) BTW this need a non backward compatible change now Any objections to bump version to 2.0-SNAPSHOT and apply this change ? Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy [1] https://jira.codehaus.org/browse/MSHADE-112 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release maven-shade-plugin 1.7.1
+1 (binding) On Wed, Jun 27, 2012 at 7:53 AM, Benson Margulies bimargul...@gmail.com wrote: Hi, We solved 1 issues: ** Bug * [MSHADE-123] - 1.7 Causes failures in other plugins make basedir point to the build dir There are still plenty of issues left in JIRA. Staging repo: https://repository.apache.org/content/repositories/maven-282/ https://repository.apache.org/content/repositories/maven-282/maven-shade-plugin-1.7.1-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-1.7.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MSHADE-120
The truth of the matter is that the only way to get a reliable timeline is if you make the fix yourself and give us a patch. Codehaus JIRA is not currently available, so I can't check to see if there's a complete test case attached to the JIRA, which would improve the likelihood that one of us chickens would attempt to address it. On Wed, Jun 27, 2012 at 11:45 AM, Saurabh Ajmera sajm...@usc.edu wrote: Hi, I would like to bring attention to http://jira.codehaus.org/browse/MSHADE-120. Its a bug regarding the createSourceJar not including source from the current maven module. Do you guys have any timeline on when will this be fixed and release? Hopefully soon! Thank you, Saurabh Ajmera - 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: New annotation system
Does @component inside the javadoc map to the @Component here? It it necessary to also have an @Parameter for read-only and required with an @Component? On Wed, Jun 27, 2012 at 3:31 PM, Olivier Lamy ol...@apache.org wrote: 2012/6/27 Marc Pasteur marc.past...@gmail.com: Hi https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins? Yup. We used names very similar with doclet. You can have a look here http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html Regards, Marc Le 27 juin 2012 20:45, Benson Margulies bimargul...@gmail.com a écrit : Could someone point me at a tutorial for this? We're changing shade to depend on M3, so we might as well move it to this. - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Shade plugin non backward compatible change
Here's my proposed plan. 1) I do something about MSHADE-123: move the default back to basedir. 2) I release 1.7.1. 3) You move the next version to 2.0 or 3.0, and fix MSHADE-112. 4) I apply the patch to MSHADE-103 that requires us to depend on Maven 3. 5) anyone who really wants a fix for Maven 2 after this branches. On Tue, Jun 26, 2012 at 4:56 PM, Olivier Lamy ol...@apache.org wrote: Hi, I don't know if you have a look @ MSHADE-112 Basically the goal is to be able to pass more and more parameters to the Shader. This need to change - void shade( SetFile jars, File uberJar, ListFilter filters, ListRelocator relocators, - ListResourceTransformer resourceTransformers ) + void shade( ShadeRequest shadeRequest ) throws IOException, MojoExecutionException; As it adding more parameters in the future tru ShadeRequest class will be more easy (and backward compatible) BTW this need a non backward compatible change now Any objections to bump version to 2.0-SNAPSHOT and apply this change ? Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy [1] https://jira.codehaus.org/browse/MSHADE-112 - 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
MSHADE-123: call for help
Folks,
I've dug a hole (reported by) MSHADE-123 and I don't know what to do about this.
I dug the hole via the changes to move the default location of the
dependency reduced pom from the project basedir to target. Having the
drp in the basedir led to chaos when multiple builds ran in parallel
(all set with distinct output directories).
MavenProject.java defines getBasedir() to be the containing dir of the
pom, period. So if the drp isn't in the base dir, anything that runs
after shade is going to get an unpleasant surprise if it tries to use
${basedir} for something.
One possibly mitigation would be to set the default for the drp back
to the basedir, so that only crazy people like me would move it
someplace else.
A bigger fix would be to change MavenProject.java to allow an explicit
setting of basedir to be someplace other than where the pom lives.
Then shade could set it to the original basedir.
Thoughts?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] [RESULT] Release Maven Shade Plugin version 1.7
Hi, The vote has passed with the following result : +1 (binding): benson margulies, olivier lamy, mark struberg +1 (non binding): none I will promote the artifacts to the central repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Shade Plugin 1.7 Released
The Maven team is pleased to announce the release of the Maven Shade Plugin, version 1.7 Repackages the project classes together with their dependencies into a single uber-jar, optionally renaming classes or removing unused classes. http://maven.apache.org/plugins/maven-shade-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version1.7/version /plugin Release Notes - Maven Shade Plugin - Version 1.7 Bug * [MSHADE-119] slash-leading classpath resources not properly rewritten when repackaging classes * [MSHADE-115] Temporary dependency-reduced-pom.xml in basedir causes problems within shared build trees * [MSHADE-107] ArrayIndexOutOfBoundsException when using minimizeJar with shade plugin * [MSHADE-75] Package maven multimodule project with shade plugin : error in opening zip on directory Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-shade-1.7
I need two more votes ... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Shade Plugin version 1.7
Come to think of it, I forgot to count myself. Thanks, Mark, we're now good to go. On Thu, May 31, 2012 at 7:21 AM, Mark Struberg strub...@yahoo.de wrote: +1 source looks good, test with 1 of my projects was fine, gpg and hashes are ok. License and Notice files do fit, deps are IP clean. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Monday, May 28, 2012 2:33 PM Subject: [VOTE] Release Maven Shade Plugin version 1.7 Hi, We solved 4 issues: Release Notes - Maven 2.x Shade Plugin - Version 1.7 ** Bug * [MSHADE-75] - Package maven multimodule project with shade plugin : error in opening zip on directory * [MSHADE-107] - ArrayIndexOutOfBoundsException when using minimizeJar with shade plugin * [MSHADE-115] - Temporary dependency-reduced-pom.xml in basedir causes problems within shared build trees * [MSHADE-119] - slash-leading classpath resources not properly rewritten when repackaging classes There are still 17 issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MSHADE+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-145/ https://repository.apache.org/content/repositories/maven-145/org/apache/maven/plugins/maven-shade-plugin/1.7/maven-shade-plugin-1.7-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-1.7/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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
[VOTE] Release Maven Shade Plugin version 1.7
Hi, We solved 4 issues: Release Notes - Maven 2.x Shade Plugin - Version 1.7 ** Bug * [MSHADE-75] - Package maven multimodule project with shade plugin : error in opening zip on directory * [MSHADE-107] - ArrayIndexOutOfBoundsException when using minimizeJar with shade plugin * [MSHADE-115] - Temporary dependency-reduced-pom.xml in basedir causes problems within shared build trees * [MSHADE-119] - slash-leading classpath resources not properly rewritten when repackaging classes There are still 17 issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MSHADE+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-145/ https://repository.apache.org/content/repositories/maven-145/org/apache/maven/plugins/maven-shade-plugin/1.7/maven-shade-plugin-1.7-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-1.7/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Alphas and betas: really?
One of the quirks of the Maven community, as seen from the outside, is the tendency to call things 'alpha' and 'beta'. I think that this is confusing. Most people assume that an 'alpha' has significant instability, and should be used only by the few and the brave. Even a 'beta' would generally raise qualms about production. Yet we have things that drift along with those terms in their version numbers for years on end, and we even sometimes make the superpom default to them. In my view, anyone releasing something with one of these 'aged' alpha or beta versions should ask themselves if there's any good reason *not* to just declare '1.0'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Shade 1.7
Unless someone objects, I'll spin maven-shade-plugin 1.7 tomorrow: Release Notes - Maven 2.x Shade Plugin - Version 1.7 ** Bug * [MSHADE-75] - Package maven multimodule project with shade plugin : error in opening zip on directory * [MSHADE-107] - ArrayIndexOutOfBoundsException when using minimizeJar with shade plugin * [MSHADE-115] - Temporary dependency-reduced-pom.xml in basedir causes problems within shared build trees * [MSHADE-119] - slash-leading classpath resources not properly rewritten when repackaging classes - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Board report request
On Fri, May 25, 2012 at 11:56 PM, Olivier Lamy ol...@apache.org wrote: Each Apache TLP project send a report to the ASF Board. This report is reviewed by the board and included in the minutes of the board meeting. See https://whimsy.apache.org/board/minutes/ And while any committer can serve as an RM, only a PMC member can edit the file to add the release to the report. -- Olivier 2012/5/26 Chris Graham chrisgw...@gmail.com: In English, what does that request mean? -Chris Sent from my iPhone On 26/05/2012, at 12:37 AM, Mark Hobson ma...@apache.org wrote: Hi, Could a PMC add Maven Release Plugin 2.3.1 to the next board report please? Thanks, Mark - 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
Looking for advice from shade-y characters on MSHADE-119
The problem here is that we need to relocate /a/b/c to /q/r/s. However, since relocations are stated in terms of a.b.c form and not path form, there's no syntax that maps. Unless, of course, a pattern of a.b.c - q.r.s should just work for getClass().getResource(/a/b/c); It seems reasonable to me, but perhaps I'm missing something? Any thoughts from deep-shade thinkers would be helpful here. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Looking for advice from shade-y characters on MSHADE-119
On Sat, May 26, 2012 at 1:31 PM, Dawid Weiss dawid.we...@gmail.com wrote: Ideally, this should be configurable via plugins because there is simply no way to predict what people may come up with? As far as I can see, a very simple change to shade allows a/b/c to match /a/b/c, and I have yet to think of a problem with it. That log message, however, is nuts. Searching in classpath and then logging that file path? I'd file that as a bug in Velocity. The relevant fragment from velocity is not even consistent -- look: inputStream = getClass().getResourceAsStream(/org/apache/velocity/runtime/defaults/velocity.properties); configuration.load(inputStream); if(log.isDebugEnabled()) log.debug(Default Properties File: + (new File(org/apache/velocity/runtime/defaults/velocity.properties)).getPath()); So they use the '/' leading form to lookup the resource but they report something else (and a file!, not a resource). Dawid On Sat, May 26, 2012 at 10:00 PM, Benson Margulies bimargul...@gmail.com wrote: The problem here is that we need to relocate /a/b/c to /q/r/s. However, since relocations are stated in terms of a.b.c form and not path form, there's no syntax that maps. Unless, of course, a pattern of a.b.c - q.r.s should just work for getClass().getResource(/a/b/c); It seems reasonable to me, but perhaps I'm missing something? Any thoughts from deep-shade thinkers would be helpful here. - 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: Looking for advice from shade-y characters on MSHADE-119
Velocity has a nasty reputation for problems on the classpath. I've fought with it on CXF. However, if I'm right, the immediate problem is trivial to fix. In SimpleRelocator, I added this || clause to 'canRelocatePath'. If no one pipes up with a reason why this would cause a disaster, I'm going to commit it. // Allow for annoying option of an extra / on the front of a path. See MSHADE-119; comes from getClass().getResource(/a/b/c.properties). return path.startsWith( pathPattern ) || path.startsWith ( / + pathPattern ); On Sat, May 26, 2012 at 2:05 PM, Dawid Weiss dawid.we...@gmail.com wrote: That log message, however, is nuts. Searching in classpath and then logging that file path? I'd file that as a bug in Velocity. It is definitely an bad code pattern -- should be either class-relative resource or searched via classloader, not class + '/' prefix). I see this from time to time though; it'll be hard to rule out in general and will recur from time to time I bet. Dawid - 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] Release Maven Release Plugin version 2.3.1
+1 (binding) On Fri, May 25, 2012 at 1:54 AM, Mark Hobson markhob...@gmail.com wrote: Vote is nearing completion and need one more binding vote, anyone? Thanks, Mark On 22 May 2012 20:48, Olivier Lamy ol...@apache.org wrote: +1 2012/5/22 Mark Hobson ma...@apache.org: Hi, We solved 3 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=18526 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11144status=1 Staging repo: https://repository.apache.org/content/repositories/maven-113/ https://repository.apache.org/content/repositories/maven-113/org/apache/maven/release/maven-release/2.3.1/maven-release-2.3.1-source-release.zip Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.3.1/ (once synced) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Mark - 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 - 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] Maven Compiler Plugin 2.5
Why not a 2.4.x release given the single issue? On Thu, May 24, 2012 at 1:19 PM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Maven Compiler Plugin 2.5. We fixed 1 issue: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130version=18466 Staging repository: https://repository.apache.org/content/repositories/maven-135/ Staged Site: http://maven.apache.org/plugins/maven-compiler-plugin-2.5 (not yet synced). Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +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] Maven Compiler Plugin 2.5
K. +1 On Thu, May 24, 2012 at 1:28 PM, Olivier Lamy ol...@apache.org wrote: Because I added new configuration parameter and upgrade with a new plexus-compiler version 2012/5/24 Benson Margulies bimargul...@gmail.com: Why not a 2.4.x release given the single issue? On Thu, May 24, 2012 at 1:19 PM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Maven Compiler Plugin 2.5. We fixed 1 issue: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130version=18466 Staging repository: https://repository.apache.org/content/repositories/maven-135/ Staged Site: http://maven.apache.org/plugins/maven-compiler-plugin-2.5 (not yet synced). Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +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 -- 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: Shade and the dependency-reduced-pom
On Tue, May 22, 2012 at 1:33 AM, Brett Porter br...@apache.org wrote: On 22/05/2012, at 1:35 PM, Benson Margulies wrote: On Mon, May 21, 2012 at 10:58 PM, Brett Porter br...@apache.org wrote: On 22/05/2012, at 12:22 PM, Benson Margulies wrote: Brett, I wrote the code today. I saw that... but didn't you send this afterwards? I thought you were looking for a way to trim it back again to avoid extra maintenance/risk of os-specific bugs. It went like this: A few days ago, I started on this, originally thinking it could be done with URI.relativize. Discovered I was wrong. Then I found the SO post that you found, and grabbed some code it pointed to, and tried to clean it up, with poor initial success. So, I sent out the email in case someone had a magic wand. Having some time on my hands today and no wand having arrived, I thought through the problem more carefully, rewrote the code, and convinced myself that it would cover the plausible use cases. I'm just not too worried about someone coding some bizarre other-drive-letter pathname into a POM as the desired location for a dependency-reduced POM. Checked it all in, ant send out email fishing for testers. OK... I just read dev@ before commits@ and got the order back to front. Just trying to help :) Well, of course, since you are upside down. I'm most grateful for your attention here, really I am. I'm still wondering where the method I was thinking of is... Me too. - Brett -- 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
Shade and the dependency-reduced-pom
MSHADE-115 reports the unpleasant consequences of putting the dependency-reduced-pom into the basedir instead of target. I'm working on a fix. The fix needs a function that can relativize one pathname to another. I'm surprised that there doesn't seem to be one of those lying about ... is there one in Plexus that I've perhaps missed? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Shade and the dependency-reduced-pom
Brett, I wrote the code today. On May 21, 2012, at 6:51 PM, Brett Porter br...@apache.org wrote: http://stackoverflow.com/questions/204784/how-to-construct-a-relative-path-in-java-from-two-absolute-paths-or-urls http://plexus.codehaus.org/plexus-utils/apidocs/org/codehaus/plexus/util/FileUtils.html#resolveFile(java.io.File, java.lang.String) I was sure there was one around called relativize, but I can't find it. Maybe was thinking of the URI one. I remember dealing with the extensive Windows edge cases and so on - probably in Archiva or Wagon/Release/SCM. Your best bet might be to use commons-io's normalize on both paths and then chop the common path-delimited substring. I don't suppose you can avoid resolving it though, and just prepend ../ as long as you know the depth from the original project, and know that the previous value was already relative? Don't forget to cover the Maven 3 case where relativePath/relativePath turns off the default. Cheers, Brett On 22/05/2012, at 6:42 AM, Benson Margulies wrote: MSHADE-115 reports the unpleasant consequences of putting the dependency-reduced-pom into the basedir instead of target. I'm working on a fix. The fix needs a function that can relativize one pathname to another. I'm surprised that there doesn't seem to be one of those lying about ... is there one in Plexus that I've perhaps missed? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-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
Re: Shade and the dependency-reduced-pom
On Mon, May 21, 2012 at 10:58 PM, Brett Porter br...@apache.org wrote: On 22/05/2012, at 12:22 PM, Benson Margulies wrote: Brett, I wrote the code today. I saw that... but didn't you send this afterwards? I thought you were looking for a way to trim it back again to avoid extra maintenance/risk of os-specific bugs. It went like this: A few days ago, I started on this, originally thinking it could be done with URI.relativize. Discovered I was wrong. Then I found the SO post that you found, and grabbed some code it pointed to, and tried to clean it up, with poor initial success. So, I sent out the email in case someone had a magic wand. Having some time on my hands today and no wand having arrived, I thought through the problem more carefully, rewrote the code, and convinced myself that it would cover the plausible use cases. I'm just not too worried about someone coding some bizarre other-drive-letter pathname into a POM as the desired location for a dependency-reduced POM. Checked it all in, ant send out email fishing for testers. On May 21, 2012, at 6:51 PM, Brett Porter br...@apache.org wrote: http://stackoverflow.com/questions/204784/how-to-construct-a-relative-path-in-java-from-two-absolute-paths-or-urls http://plexus.codehaus.org/plexus-utils/apidocs/org/codehaus/plexus/util/FileUtils.html#resolveFile(java.io.File, java.lang.String) I was sure there was one around called relativize, but I can't find it. Maybe was thinking of the URI one. I remember dealing with the extensive Windows edge cases and so on - probably in Archiva or Wagon/Release/SCM. Your best bet might be to use commons-io's normalize on both paths and then chop the common path-delimited substring. I don't suppose you can avoid resolving it though, and just prepend ../ as long as you know the depth from the original project, and know that the previous value was already relative? Don't forget to cover the Maven 3 case where relativePath/relativePath turns off the default. Cheers, Brett On 22/05/2012, at 6:42 AM, Benson Margulies wrote: MSHADE-115 reports the unpleasant consequences of putting the dependency-reduced-pom into the basedir instead of target. I'm working on a fix. The fix needs a function that can relativize one pathname to another. I'm surprised that there doesn't seem to be one of those lying about ... is there one in Plexus that I've perhaps missed? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-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 -- 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
[RESULT] [VOTE] Release maven-changes-plugin 2.7.1
The vote passed. binding +1: bimargulies, hboutemy, olamy, Mark Struberg nonbinding +1: ltheussl - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Am I a dev or am't I?
Has the POM with me in it not trickled down yet? [ERROR] Failed to execute goal org.apache.maven.plugins:maven-changes-plugin:2.6:announcement-mail (default-cli) on project maven-changes-plugin: Missing developer with id 'bimargulies' in the developers section in your pom. - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] maven-changes-plugin 2.7.1 released
The Maven team is pleased to announce the release of the Maven Changes Report Plugin, version 2.7.1 Creates a release history for inclusion into the site and assists in generating an announcement mail. http://maven.apache.org/plugins/maven-changes-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-changes-plugin/artifactId version2.7.1/version /plugin Release Notes - Maven Changes Report Plugin - Version 2.7.1 Bug * [MCHANGES-281] jira report fails with Jira 5.0.3 (NPE) Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release maven-changes-plugin 2.7.1
Hi, We solved 1 issues: MCHANGES-281 There are still plenty of issues left in JIRA. Staging repo: https://repository.apache.org/content/repositories/maven-077/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.7.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here's my +1. Release Notes - Maven 2.x Changes Plugin - Version 2.7.1 ** Bug * [MCHANGES-281] - jira report fails with Jira 5.0.3 (NPE) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Intent to release maven-changes-plugin 2.8 / 2.7.1
A user has asked for a quick turn on a blocking bug with the changes plugin when used with JIRA 5. I'm willing to turn the crank. Does anyone have strong feelings about 2.8 versus 2.7.1 in this case? Does anyone object? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Release Maven Changes Plugin version 2.7
oops. Sorry. On Tue, May 1, 2012 at 1:11 PM, Lukas Theussl ltheu...@apache.org wrote: For the record: my vote is not binding. Thanks for the release anyway! :) -Lukas Benson Margulies wrote: Subject: Hi, The vote has passed with the following result : +1 (binding): hboutemy, bimargulies, olamy, ltheussl +1 (non binding): Tony Chemit I will promote the artifacts to the central repo. - 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
[RESULT] [VOTE] Release Maven Changes Plugin version 2.7
Subject: Hi, The vote has passed with the following result : +1 (binding): hboutemy, bimargulies, olamy, ltheussl +1 (non binding): Tony Chemit I will promote the artifacts to the central repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] maven-changes-plugin 2.7 released
The Maven team is pleased to announce the release of the Maven Changes Report Plugin, version 2.7 Creates a release history for inclusion into the site and assists in generating an announcement mail. http://maven.apache.org/plugins/maven-changes-plugin You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-changes-plugin/artifactId version2.7/version /plugin Release Notes - Maven Changes Report Plugin - Version 2.7 Bug * [MCHANGES-262] Using custom issue types mapping (MCHANGES-245) throws a llegalArgumentException * [MCHANGES-261] Mail sender specification pointlessly difficult * [MCHANGES-237] The goal jira-report always results in HTTP 400 error when accessing https://*.jira.com Improvement * [MCHANGES-279] ability to skip for Jira is offlince * [MCHANGES-264] [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata * [MCHANGES-213] Update Velocity 1.7 New Feature * [MCHANGES-275] versionPrefix configurable by expression 'changes.versionPrefix' * [MCHANGES-272] Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions. * [MCHANGES-76] Add an option to hava an aggregated Changes Report Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] maven-changes--plugin 2.7
The Maven team is pleased to announce the release of the Maven Changes Report Plugin, version 2.7 Creates a release history for inclusion into the site and assists in generating an announcement mail. http://maven.apache.org/plugins/maven-changes-plugin You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-changes-plugin/artifactId version2.7/version /plugin Release Notes - Maven Changes Report Plugin - Version 2.7 Bug * [MCHANGES-262] Using custom issue types mapping (MCHANGES-245) throws a llegalArgumentException * [MCHANGES-261] Mail sender specification pointlessly difficult * [MCHANGES-237] The goal jira-report always results in HTTP 400 error when accessing https://*.jira.com Improvement * [MCHANGES-279] ability to skip for Jira is offlince * [MCHANGES-264] [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata * [MCHANGES-213] Update Velocity 1.7 New Feature * [MCHANGES-275] versionPrefix configurable by expression 'changes.versionPrefix' * [MCHANGES-272] Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions. * [MCHANGES-76] Add an option to hava an aggregated Changes Report Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Don't update any parents to use maven-changes-plugin 2.7
I discovered MCHANGES-280 in the process of releasing 2.7, after I had already pushed to central (or at least towards). I'll look into the fix; clearly, we're short an integration test here somehow or another. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] release maven parent pom version 22
I've staged a release of org.apache.maven:maven-parent:22 to pick up a few new developer elements and other miscellaneous things. If anyone -1's because they wished I've warned them so they could add something, I'll unwind. Otherwise, this vote will be open for the usual 72 hours. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] release maven parent pom version 22
On Mon, Apr 30, 2012 at 5:03 PM, Dennis Lundberg denn...@apache.org wrote: On 2012-04-30 22:56, Benson Margulies wrote: I've staged a release of org.apache.maven:maven-parent:22 to pick up a few new developer elements and other miscellaneous things. If anyone -1's because they wished I've warned them so they could add something, I'll unwind. I'd really like to include the new versions of the site plugin in the next parent. That vote ends in about an hour. Fair enough. I propose to burn version 22; I'll drop the repo, and you can create 23 and start a vote for it. Otherwise, this vote will be open for the usual 72 hours. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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] release maven parent pom version 22
On Mon, Apr 30, 2012 at 5:09 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: sorry, I have a few points: - new m-compiler-p and m-site-p versions deserve a new parent pom release train, starting with ASF - you're defined twice in the pom :) - I tried to prepare a site for parent poms: [1], there is no specific documentation on the publishing while releasing, but I can help and we should see if it deserve another release procedure page then IMHO, we should wait for a few days and make a vote for ASF parent, then one for the 4 Maven-specific ones. If you want, I can do it. Now we have a lot of reasons. I'm happy to defer to you. I added myself because site claimed I wasn't in there, and clearly I wasn't paying enough attention. Regards, Hervé [1] http://maven.apache.org/pom/index.html Le lundi 30 avril 2012 16:56:07 Benson Margulies a écrit : I've staged a release of org.apache.maven:maven-parent:22 to pick up a few new developer elements and other miscellaneous things. If anyone -1's because they wished I've warned them so they could add something, I'll unwind. Otherwise, this vote will be open for the usual 72 hours. - 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] release maven parent pom version 22
oops, I mean 'changes claimed I wasn't in there'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: aggregate modules with asf-svnpubsub-plugin
On Sun, Apr 29, 2012 at 11:06 AM, Eric Charles eric.char...@u-mangate.com wrote: Hi, I am trying the asf-svnpubsub-plugin 1.0-SNAPSHOT with a multimodule project, and it checkouts the whole pubScmUrl in each submodule, which takes time and is not useful for me (I only need to generate and publish on the top module). Is this the expected behavior? I searched the result of -help but didn't find a configuration for this, instead, I read ...here that an entire directory in svn is dedicated to the publication process for this project. In the aggregate case, this is going to take some doing. I haven't worked out the multi-module cases entirely. Thx, -- eric | http://about.echarles.net | @echarles - 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
[VOTE] Release Maven Changes Plugin version 2.7
Hi, We resolved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI-QX7G-9IAS%7Cb183085c89ca85abde86540c1f02cb433b8719dd%7Cloutversion=17447styleName=TextprojectId=11212Create=Create There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-005/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.7/ There may be a delay while this copies itself. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 /to save people a click, here's the issue list/ Release Notes - Maven 2.x Changes Plugin - Version 2.7 ** Bug * [MCHANGES-237] - The goal jira-report always results in HTTP 400 error when accessing https://*.jira.com * [MCHANGES-261] - Mail sender specification pointlessly difficult * [MCHANGES-262] - Using custom issue types mapping (MCHANGES-245) throws a llegalArgumentException ** Improvement * [MCHANGES-213] - Update Velocity 1.7 * [MCHANGES-264] - [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata * [MCHANGES-279] - ability to skip for Jira is offlince ** New Feature * [MCHANGES-76] - Add an option to hava an aggregated Changes Report * [MCHANGES-272] - Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions. * [MCHANGES-275] - versionPrefix configurable by expression 'changes.versionPrefix' - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Changes Plugin version 2.7
The staging site is actually at http://maven.apache.org/plugins/maven-changes-plugin-2.7/plugins/maven-changes-plugin/. And I'm the one who added the text to the page saying, 'check for staging problems before running the release'. Sigh. Also, here's my own +1, which I forgot. On Fri, Apr 27, 2012 at 8:34 AM, Benson Margulies bimargul...@gmail.com wrote: Hi, We resolved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI-QX7G-9IAS%7Cb183085c89ca85abde86540c1f02cb433b8719dd%7Cloutversion=17447styleName=TextprojectId=11212Create=Create There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-005/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.7/ There may be a delay while this copies itself. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 /to save people a click, here's the issue list/ Release Notes - Maven 2.x Changes Plugin - Version 2.7 ** Bug * [MCHANGES-237] - The goal jira-report always results in HTTP 400 error when accessing https://*.jira.com * [MCHANGES-261] - Mail sender specification pointlessly difficult * [MCHANGES-262] - Using custom issue types mapping (MCHANGES-245) throws a llegalArgumentException ** Improvement * [MCHANGES-213] - Update Velocity 1.7 * [MCHANGES-264] - [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata * [MCHANGES-279] - ability to skip for Jira is offlince ** New Feature * [MCHANGES-76] - Add an option to hava an aggregated Changes Report * [MCHANGES-272] - Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions. * [MCHANGES-275] - versionPrefix configurable by expression 'changes.versionPrefix' - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Changes Plugin version 2.7
On Fri, Apr 27, 2012 at 5:54 PM, Dennis Lundberg denn...@apache.org wrote: On 2012-04-27 17:40, Benson Margulies wrote: The staging site is actually at http://maven.apache.org/plugins/maven-changes-plugin-2.7/plugins/maven-changes-plugin/. And I'm the one who added the text to the page saying, 'check for staging problems before running the release'. Sigh. This is a known bug in the Site Plugin. It is fixed in the new versions that are coming out. I took the liberty of moving the site to its proper place, i.e. to the URL in your original mail. thanks. Also, here's my own +1, which I forgot. On Fri, Apr 27, 2012 at 8:34 AM, Benson Margulies bimargul...@gmail.com wrote: Hi, We resolved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI-QX7G-9IAS%7Cb183085c89ca85abde86540c1f02cb433b8719dd%7Cloutversion=17447styleName=TextprojectId=11212Create=Create There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-005/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.7/ There may be a delay while this copies itself. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 /to save people a click, here's the issue list/ Release Notes - Maven 2.x Changes Plugin - Version 2.7 ** Bug * [MCHANGES-237] - The goal jira-report always results in HTTP 400 error when accessing https://*.jira.com * [MCHANGES-261] - Mail sender specification pointlessly difficult * [MCHANGES-262] - Using custom issue types mapping (MCHANGES-245) throws a llegalArgumentException ** Improvement * [MCHANGES-213] - Update Velocity 1.7 * [MCHANGES-264] - [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata * [MCHANGES-279] - ability to skip for Jira is offlince ** New Feature * [MCHANGES-76] - Add an option to hava an aggregated Changes Report * [MCHANGES-272] - Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions. * [MCHANGES-275] - versionPrefix configurable by expression 'changes.versionPrefix' - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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: the maven build-from-source-plugin
Here's a use case, and I think a way to make something that works. Project A wants to make use of a dependency from project B. There is, however a bug. Project B is, for whatever reason, not going to release a bugfix any time soon. Project A really doesn't want to establish a full fork. In the good old days of open source, A would distribute a patch and leave it to their users to apply it. Now, consider a Maven project that is part of the tree of A. It's g/a/v says: 'our.fixed.version':'of-project-b':v. It uses a maven plugin to download the source of B. It applies a patch. It then uses the invoker, or anrun, or something, to build B. It then needs to attach the results so that the reactor can see them, and all is well. (It can shade or not as appropriate to circumstances). There is also a more philosophical use case that I won't bore you with. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal: the maven build-from-source-plugin
On Wed, Apr 25, 2012 at 10:45 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 25 April 2012 14:46, Benson Margulies bimargul...@gmail.com wrote: Here's a use case, and I think a way to make something that works. Project A wants to make use of a dependency from project B. There is, however a bug. Project B is, for whatever reason, not going to release a bugfix any time soon. Project A really doesn't want to establish a full fork. In the good old days of open source, A would distribute a patch and leave it to their users to apply it. Now, consider a Maven project that is part of the tree of A. It's g/a/v says: 'our.fixed.version':'of-project-b':v. without a provides (note the 's' is not a 'd') scope or equivalent that will cause endless problems with the transitive dependency hull. They would need to keep the G:A the same and vary the V... and that will hit issues publishing to Central. No publication to central. That's a 'central' principle here. It uses a maven plugin to download the source of B. It applies a patch. It then uses the invoker, or anrun, or something, to build B. It then needs to attach the results so that the reactor can see them, and all is well. (It can shade or not as appropriate to circumstances). There is also a more philosophical use case that I won't bore you with. - 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
Proposal: the maven build-from-source-plugin
From time to time, there is an impedance mismatch between the desires of an open source development community and the nature of Maven as a *binary* dependency management system. While I wouldn't, for a moment, suggest tampering with the existing binary system, I was wondering how hard it would be to build a plugin, perhaps inspired by the scm plugin, that could download and build source. One hopes to discover that the -sources artifact for a gav is, in fact, comprehensive and buildable. Could the results of such a build enter the reactor without core changes, or would there need to be a two-phase approach? This, of course, assumes that the sources are (a) buildable and (b) buildable with maven. (Give or take antrun or other scripting.) A further interesting wrinkle would be to add patch application to the mix -- possibly a problem bounded by the need for a Java implementation of 'patch'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Changes Plugin
There are two issues fixed since the last release. Neither of them relate to the IBM JDK. Are these unapplied patches? On Sun, Apr 22, 2012 at 8:05 AM, Chris Graham chrisgw...@gmail.com wrote: The last time I looked, there were some outstanding issues in the plugin. The IBM JDK being the that effects me the most. Any chance we can roll a new release in that one? -Chris Sent from my iPhone - 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
maven-changes-plugin release
I just did a sweep on patches and trivia in the changes plugin. If we made a release now, we'd get the following. Anyone care to push on anything else first? ** Bug * [MCHANGES-237] - The goal jira-report always results in HTTP 400 error when accessing https://*.jira.com * [MCHANGES-261] - Mail sender specification pointlessly difficult * [MCHANGES-262] - Using custom issue types mapping (MCHANGES-245) throws a llegalArgumentException ** Improvement * [MCHANGES-213] - Update Velocity 1.7 * [MCHANGES-264] - [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata * [MCHANGES-279] - ability to skip for Jira is offlince ** New Feature * [MCHANGES-76] - Add an option to hava an aggregated Changes Report * [MCHANGES-275] - versionPrefix configurable by expression 'changes.versionPrefix' - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
On Tue, Mar 20, 2012 at 4:45 PM, Jason Chaffee jason.chaf...@betfair.com wrote: Just a suggestion. If you can find some people who are not currently commuters and are interested in do thing just this very thing, could they be a partial committer, only working on the RPM's and not the other parts of maven? In my opinion, this is the spirit of open source software. I know everywhere I have been my IT/OPS wanted RPM's for maven. Jason It's actually simpler than this. If someone posts a reasonable patch -- where reasonable means (in my opinion), could be part of the automated Jenkins builds, doesn't inordinately inconvenience people building the core on Windows, then some committer might commit it. *I* might commit it. If one of my fellow PMC members found it bottomlessly horrible, they could exercise their post-commit review powers and tell me to yank it until we had a formal vote. Once it was in place, then the next question would be, Would any release manager take responsibility for including the results in a vote? Now, keep in mind that Apache releases are SOURCE releases. The binaries are for convenience only. Still, I agree with Stephen C. that it would be bad form to put RPMs on /dist that hadn't been supervised by the PMC. The final question, then, as Stephen has pointed out, would be, would a sufficiency of PMC members vote +1 and not -1 for a release with them. So far, no PMC member has expressed any enthusiasm for that step. On 3/20/12 7:47 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: To get the RPMs released, you are going to have to find 3xPMC members willing to vote +1 for each time you run the release. Your best option is to have the RPMs as a separate module that depends on org.apache.maven:apache-maven and repackages that producing just an RPM. Do not try to integrate it into the core build of Maven, as you will have too few PMC members willing to vote on the RPM being in the core dist. Profiles would be evil for this case... separate module outside of the main build is fine. -Stephen P.S. in case it was not clear from my previous mail, I will not be using what little time I have to vote on RPM releases. There are currently 24 people on the PMC list. If you cannot find at least 3 of them willing to consider voting +1 on RPM releases, then you are SooL On 20 March 2012 14:19, Stanislav Ochotnicky sochotni...@redhat.com wrote: I would *really* like for maven to produce RPMs as alternative dist output, but I understand your position. I had a quick look into rpm-maven-plugin and I believe a reasonable RPM output could be achieved by using it in with non-default profile. That should also prevent any problems with building for Windows users (or all that don't really care about rpm output). Or do you consider even this approach unviable? It's OK if you do, just want to know if I should keep looking for some compromise or if it's really out of the question. One way or the other I created a simple spec/srpm based on binary maven release: Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec SRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm BINRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm I should note that I don't really intend to support this solution. But I might update this together with maven releases since I assume it should be fairly easy. Another request: would you consider adding bash-completion[1] to maven sources someplace? We have a slightly modified version in Fedora. [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion Quoting Jason van Zyl (2012-03-20 13:33:32) Stanislav, If you're going to attempt something do it as an external action that takes the output of the primary build. Don't make something that augments the standard build process. That's invasive and for people building on Windows if problems arise they can't really fix it. If you make an entirely separate build that can consume the output of the standard build then people who are interested can take a look, those who don't care aren't affected. I don't want any specific modifications made to the existing build process to accommodate RPMs. I think a separate build would be more useful as it will be specific to the task at hand and people can use it as they like to produce RPMs for themselves if they so choose. On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote: Quoting Jos Backus (2012-03-19 23:40:43) Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the
Re: RPMs for Maven 3?
On Mon, Mar 19, 2012 at 12:28 PM, Jos Backus j...@catnook.com wrote: On Mon, Mar 19, 2012 at 2:45 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Another thing I should have pointed out right away, but forgot is that alternative way would be to create rpms directly out of upstream maven release with bundled dependencies and all that. I know most people on this list would feel more comfortable with this approach and it is more simple way to achieve your goals right now. It shouldn't take more than a few minutes to create that spec file. I was really hoping for there to be a Download RPMs link to be available on the Maven website, especially since there's a plugin that makes it easy to create RPMs from Maven builds (assuming the main Maven builds use Maven to build itself). I am -1 to this. Maven is very dubiously useful without connectivity to central. A 'self-contained' Maven build is only self-contained until you try to do something interesting with it. If you have connectivity, it's better to just stick with the pattern that the maven distro is minimal and downloads the rest of what it needs from central. However, my opinion notwithstanding, the only way something like this would happen is if someone offered up a patch with a complete, automated solution. If it's easy, can someone make this happen, please? Thanks! Jos -- Jos Backus jos at catnook.com - 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: RPMs for Maven 3?
On Mon, Mar 19, 2012 at 4:14 PM, Jos Backus j...@catnook.com wrote: On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zyl ja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. 1) Easy is always in the eye of the proposer. If you want to supply a patch to the build of maven that builds an RPM that you think is useful, it might well get committed. Whether the results of running it end up on dist would be the output of more discussion. 2) I find it hard to take seriously the proposition that 'download, untar, run' is a high enough bar to fit anything interesting under it. Jos -- Jos Backus jos at catnook.com - 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: RPMs for Maven 3?
On Mon, Mar 19, 2012 at 5:08 PM, Jos Backus j...@catnook.com wrote: On Mon, Mar 19, 2012 at 1:39 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 19, 2012, at 4:14 PM, Jos Backus wrote: On Mon, Mar 19, 2012 at 11:46 AM, Jason van Zyl ja...@tesla.io wrote: I think if some 3rd party wants to provide an RPM have at it. I don't think this is something we want to create or support. [snip] Any reason why not, especially when it's easy to do so? It lowers the bar for users to deploy Maven. You're assuming it's easy to do but as an overall supported aspect of the project nothing is easy. Maybe easy for you, but not for us :-) Generating an RPM is one thing, supporting it and have it undergo the construction that RPM proponents might require like building it offline and running it under our normal gamut of tests is probably not easy. You're making an assumption that it lowers the bar, but I would argue that's for a much smaller segment of the user base then you might think -- I believe Windows users still make up the largest segment. So as I've argued in the past the value to the project overall versus the work to actually support creating an RPM is up for discussion. I don't believe it's worth the effort. Well, if installing Maven is really as easy as just unpacking a tarball, creating an RPM should not be hard. The java dependency is an issue. And then ... every RPM of a Java package I've ever seen has felt the need to take the self-contained hierarchy of the normal distro and move things to other places. Config to /etc, logs to /var/log, cetra. So, right, one of us could probably come up with a trivial RPM, which would be trivially rejected by all of the distro packages. I could also mention the question of equal rights for debian users, and don't even get me started on Gentoo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Shade Plugin 1.6
+1 On Thu, Mar 15, 2012 at 9:02 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: +1 Hervé Le jeudi 15 mars 2012 10:56:34 Olivier Lamy a écrit : Hello, I'd like to release Apache Maven Shade Plugin 1.6. We fixed 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18042styleName=Te xtprojectId=11540Create=Create Staging repo: https://repository.apache.org/content/repositories/maven-078/ Staged site: http://maven.apache.org/plugins/maven-shade-plugin-1.6 [-1] [0] [+1] Thanks, - 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: next steps with the cms integration
On Tue, Mar 13, 2012 at 3:59 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le lundi 12 mars 2012 19:31:38 Benson Margulies a écrit : How do you think we should tell text and binary files? svn mime type (probably not accessible). Suffix? Patterns in configuration? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org good question Java Activation Framework, hoping it contains every mime type we need? No, but Apache Tika can do something for us here. It will just be slower than comparing file names to suffix patterns. I didn't have time to investigate Regards, Hervé - 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: next steps with the cms integration
How do you think we should tell text and binary files? svn mime type (probably not accessible). Suffix? Patterns in configuration? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: next steps with the cms integration
On Sun, Mar 11, 2012 at 3:48 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: First the site content, editable with the CMS webui: to me, it's working and complete. A few people managed content modification and publishing with success. Notice that Doxia site content has been added as a subsite: we did the minimal integration, so the content can't be edited through the CMS web UI, but you can edit content on svn and the CMS build then svnpubsub will follow. Second components versioned sites. We have a goosd starting point, but details to decide. 1. asf-svnpubsub-plugin It is working: there are few FIXMEs or TODOs I added that need your review, since I'm not sure of the intent. And IMHO, the asf-svnpubsub-plugin could be renamed to maven-site-scm-publish-plugin or something like it (and perhaps later even merged into m-site-p as a special case of publishing where a checkout needs to be done before pushing content) I'll focus here. I'm at your disposal in terms of 'merge to the site plugin.' If you think that's a good idea, please give me some starting notion of where to put it, and I'll set to work. Otherwise I'll rename and clean up. If we give it that name do we put it into the regular plugin tree at this point? 2. where in svn to publish content and determine versions? I made 2 proposals: - simple import of each release, without history between imports - a real history in svn, always importing/updating at the same svn place Then we have to write down precise mvn + svn instruction to do the publication and decide whether it is ok for everyone to follow (doesn't need to do a full site svn checkout, for instance) 3. initial import of the actual site content on people.a.o src/content/resources/extpaths.txt contains an overall analysis of what has to be imported and the few questions remaining IMHO, we should do the whole imports while on maventest, then we'll copy content to the final maven site svn. And of course we need real test of a release process, with a multi-module project publishing a new release of something already published in previuous versions Regards, Hervé Le samedi 10 mars 2012 14:10:18 Benson Margulies a écrit : Hervé, I've been swamped. What's next? --benson - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
next steps with the cms integration
Hervé, I've been swamped. What's next? --benson - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Modifying the site lifecycle
On Thu, Mar 1, 2012 at 6:17 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: if you look at committer environment [1], you'll see that there is a subversion configuration with precisely svn-eol-style.txt That's the default properties developer's svn client sets on files: here is the way properties are defined when adding a file to svn, even if SCM API doesn't tell anything about it. And when svn:eol-style=native, svn doesn't like if the file contains non-native EOLs. Then I'm sure now that the normalizeNewline method should use native EOL: svn will do the conversion if the committer added the file from Windows. The checkout by svnpubsub being done by a Unix box, Unix EOLs will appear on the site Fine. Regards, Hervé Le jeudi 1 mars 2012 13:46:55 Chris Graham a écrit : I'm confused. HTML is a text file, so what does it's EOL style matter? But you address your other question, the only way that I know is to do a propset of svn:eol-style. And I am not aware that the SCM API has the facility to do this. I'm pretty sure (as that's where I've been poking around lately) that not even the svn provider touches properties, but there are a few TODO comments in there that indicate that it could be done. -Chris On Thu, Mar 1, 2012 at 12:18 PM, Benson Margulies bimargul...@gmail.comwrote: On the subject of newlines: personally, I think that Windows newlines in HTML files are evil. However, if that is an exotic belief on my part, I don't mind changing the code to normalize to native. It would be good to know what the svn eol-style is, but I don't see how do do that through scm. - 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
