discussion on MNG-4637 : -pl switch negates recursion into sub projects
Hello, I would be very interested to have [1] implemented. Our use case is to compile a subpart of our aggregator + all associated dependencies. The current behaviour requires us to provide *all* individual modules, which defeats the purpose of aggregators. I've made a patch proposal a while ago [2] but got so far no feedback (positive or negative). I know that you don't monitor pull requests on GH for Maven, but since in my company we start having serious needs for this, I'd like to take the necessary steps for this to be integrated. I'm guessing some ITs will be required, but I just want to know if the change sounds like a reasonable one (given that is changing a bit the semantic of the '-pl' option). Thanks for your feedback, Vincent [1] http://jira.codehaus.org/browse/MNG-4637 [2] https://github.com/apache/maven-3/pull/2
Re: [VOTE] Release Apache Maven SCM 1.7
+1 Emmanuel On Thu, Apr 26, 2012 at 6:23 PM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Apache Maven SCM 1.7. We fixed 18 issues ( http://s.apache.org/SCM-1.7 ) One new feature is the support of Jazz Scm (thanks to Chris Graham !) The staging repository is available here: https://repository.apache.org/content/repositories/maven-112/ The staging site: http://maven.apache.org/scm-1.7/ (the full content is not yet sync). [+1] [0] [-1] Vote open for 72H. 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
[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: discussion on MNG-4637 : -pl switch negates recursion into sub projects
The idea sounds fine. Changing the semantics of existing functionality is not a good idea. If you can implement it such that it is purely additive, and orthogonal, to existing functionality it's much easier to evaluate. Changing how the switch might work for those using it currently is not desirable and may potentially affect people adversely. Just pick another switch name for now and that should suffice. On Apr 27, 2012, at 4:34 AM, Vincent Latombe wrote: Hello, I would be very interested to have [1] implemented. Our use case is to compile a subpart of our aggregator + all associated dependencies. The current behaviour requires us to provide *all* individual modules, which defeats the purpose of aggregators. I've made a patch proposal a while ago [2] but got so far no feedback (positive or negative). I know that you don't monitor pull requests on GH for Maven, but since in my company we start having serious needs for this, I'd like to take the necessary steps for this to be integrated. I'm guessing some ITs will be required, but I just want to know if the change sounds like a reasonable one (given that is changing a bit the semantic of the '-pl' option). Thanks for your feedback, Vincent [1] http://jira.codehaus.org/browse/MNG-4637 [2] https://github.com/apache/maven-3/pull/2 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Simplex sigillum veri. (Simplicity is the seal of truth.)
1.5 Annotations for Mojo
Hi, I'd like to work on 1.5 Annotations for Mojos. Hervé started documentation here: https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins The Stephen's idea for named without Mojo prefix looks fine (at least for me). But I would prefer to not implement (yet) the other idea with synthetic bridging classes. I can start the job next week (probably in a branch). Comments ? 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
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: 1.5 Annotations for Mojo
+100 I've had a talk about this with Simone this month. He'd done some investigation already. I think there are two separate steps to be taken. 1. Generate the plugin.xml based on both annotations and doclets 2. Extend Maven Core to understand Mojo Annotations as well The first one would already be a huge improvement for all mojo-devs. -Robert Op Fri, 27 Apr 2012 16:36:57 +0200 schreef Olivier Lamy ol...@apache.org: Hi, I'd like to work on 1.5 Annotations for Mojos. Hervé started documentation here: https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins The Stephen's idea for named without Mojo prefix looks fine (at least for me). But I would prefer to not implement (yet) the other idea with synthetic bridging classes. I can start the job next week (probably in a branch). Comments ? Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven SCM 1.7
+1 Robert Op Fri, 27 Apr 2012 14:07:34 +0200 schreef Emmanuel Venisse emmanuel.veni...@gmail.com: +1 Emmanuel On Thu, Apr 26, 2012 at 6:23 PM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Apache Maven SCM 1.7. We fixed 18 issues ( http://s.apache.org/SCM-1.7 ) One new feature is the support of Jazz Scm (thanks to Chris Graham !) The staging repository is available here: https://repository.apache.org/content/repositories/maven-112/ The staging site: http://maven.apache.org/scm-1.7/ (the full content is not yet sync). [+1] [0] [-1] Vote open for 72H. 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: 1.5 Annotations for Mojo
We have implemented a Java 5 annotation for configuration parameters (PullParameter) in the Android Maven Plugin that might be worth looking at. We are still phasing them out across the system but a good place to look at the usage is the ProguardMojo https://github.com/jayway/maven-android-plugin/blob/master/src/main/java/com/jayway/maven/plugins/android/phase04processclasses/ProguardMojo.java Manfred On Fri, April 27, 2012 9:26 am, Robert Scholte wrote: +100 I've had a talk about this with Simone this month. He'd done some investigation already. I think there are two separate steps to be taken. 1. Generate the plugin.xml based on both annotations and doclets 2. Extend Maven Core to understand Mojo Annotations as well The first one would already be a huge improvement for all mojo-devs. -Robert Op Fri, 27 Apr 2012 16:36:57 +0200 schreef Olivier Lamy ol...@apache.org: Hi, I'd like to work on 1.5 Annotations for Mojos. Hervé started documentation here: https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins The Stephen's idea for named without Mojo prefix looks fine (at least for me). But I would prefer to not implement (yet) the other idea with synthetic bridging classes. I can start the job next week (probably in a branch). Comments ? 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: 1.5 Annotations for Mojo
Hi there, I think JFrog (the Artifactory guys) has already published a set of Java 1.5 annotations for mojo development, including a m-plugin-p extension to use them. The source code is available on github [1], but unfortunately the artifacts are not available in Central (there is a ticket in JFrog's JIRA [2] regarding this problem). They even have reasonably complete documentation [3] plus it's all under ASL 2.0 AFAICS. From my own experience, these annotations work quite well. Shouldn't they be incorporated or used as a starting point? I guess starting from JFrog's annotations will not only save a considerable amount of development time, but also increase acceptance with those plugin developers which already used the existing JFrog annotations in the past. Best regards Ansgar [1] https://github.com/JFrogDev/maven-anno-mojo [2] https://issues.jfrog.org/jira/browse/ANMJ-18 [3] http://wiki.jfrog.org/confluence/display/OSS/Maven+Anno+Mojo Am 27.04.2012 16:37 schrieb Olivier Lamy ol...@apache.org: Hi, I'd like to work on 1.5 Annotations for Mojos. Hervé started documentation here: https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins The Stephen's idea for named without Mojo prefix looks fine (at least for me). But I would prefer to not implement (yet) the other idea with synthetic bridging classes. I can start the job next week (probably in a branch). Comments ? 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
Re: discussion on MNG-4637 : -pl switch negates recursion into sub projects
On 27 April 2012 01:34, Vincent Latombe vincent.lato...@gmail.com wrote: I would be very interested to have [1] implemented. Our use case is to compile a subpart of our aggregator + all associated dependencies. The current behaviour requires us to provide *all* individual modules, which defeats the purpose of aggregators. I've made a patch proposal a while ago [2] but got so far no feedback (positive or negative). I know that you don't monitor pull requests on GH for Maven, but since in my company we start having serious needs for this, I'd like to take the necessary steps for this to be integrated. I'm guessing some ITs will be required, but I just want to know if the change sounds like a reasonable one (given that is changing a bit the semantic of the '-pl' option). Thanks for your feedback, What about -am and -amd? (I have not actually used these switches, nor -pl, so this is really a question. It's just that mvn -h seems to imply they all work together.) [1] http://jira.codehaus.org/browse/MNG-4637 [2] https://github.com/apache/maven-3/pull/2 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 1.5 Annotations for Mojo
Err, I did upload to central (the 1.4.1 release). http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22br.com.ingenieux.maven.annomojo%22 I wish those could be resolved. JFrog's solution is great and it works like a charm. -- -- Aldrin Leal, ald...@leal.eng.br / http://meadiciona.com/aldrinleal On Fri, Apr 27, 2012 at 2:34 PM, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Hi there, I think JFrog (the Artifactory guys) has already published a set of Java 1.5 annotations for mojo development, including a m-plugin-p extension to use them. The source code is available on github [1], but unfortunately the artifacts are not available in Central (there is a ticket in JFrog's JIRA [2] regarding this problem). They even have reasonably complete documentation [3] plus it's all under ASL 2.0 AFAICS. From my own experience, these annotations work quite well. Shouldn't they be incorporated or used as a starting point? I guess starting from JFrog's annotations will not only save a considerable amount of development time, but also increase acceptance with those plugin developers which already used the existing JFrog annotations in the past. Best regards Ansgar [1] https://github.com/JFrogDev/maven-anno-mojo [2] https://issues.jfrog.org/jira/browse/ANMJ-18 [3] http://wiki.jfrog.org/confluence/display/OSS/Maven+Anno+Mojo Am 27.04.2012 16:37 schrieb Olivier Lamy ol...@apache.org: Hi, I'd like to work on 1.5 Annotations for Mojos. Hervé started documentation here: https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins The Stephen's idea for named without Mojo prefix looks fine (at least for me). But I would prefer to not implement (yet) the other idea with synthetic bridging classes. I can start the job next week (probably in a branch). Comments ? 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
Re: 1.5 Annotations for Mojo
I would prefer not be core change dependent. Some folks are still using 2.x . And 'classloader scanning' at runtime level will have IHMO a performance cost ! So I would prefer plugin metadata generation (the trick will be having the mix of doclet and annotations : perso I'm not sure it's a good idea to have both ? ) -- Olivier Send from a VT100 phone console Le 27 avr. 2012 18:26, Robert Scholte apa...@sourcegrounds.com a écrit : +100 I've had a talk about this with Simone this month. He'd done some investigation already. I think there are two separate steps to be taken. 1. Generate the plugin.xml based on both annotations and doclets 2. Extend Maven Core to understand Mojo Annotations as well The first one would already be a huge improvement for all mojo-devs. -Robert Op Fri, 27 Apr 2012 16:36:57 +0200 schreef Olivier Lamy ol...@apache.org : Hi, I'd like to work on 1.5 Annotations for Mojos. Hervé started documentation here: https://cwiki.apache.org/**confluence/display/MAVEN/Java+** 5+Annotations+for+Pluginshttps://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins The Stephen's idea for named without Mojo prefix looks fine (at least for me). But I would prefer to not implement (yet) the other idea with synthetic bridging classes. I can start the job next week (probably in a branch). Comments ? Thanks, --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: discussion on MNG-4637 : -pl switch negates recursion into sub projects
On 04/27/2012 01:39 PM, Hilco Wijbenga wrote: What about -am and -amd? -am does work together with -pl. Vincent's issue is that -pl must be given a full list of submodules; just passing an aggregator is not enough. For example, take top +- libs | +- lib1 | +- lib2 +- apps +- app1 | +- mod1 [lib1] | +- mod2 [] +- app2 +- mod1 [] +- mod2 [lib2] where top, libs, apps, app1, and app2 are aggregator projects. Now say you want to build the first application. What should you do? 1. 'cd apps/app1 mvn' will not work unless lib1 has been previously built; -am does not help. 2. 'mvn -pl apps/app1 -am' will just install app1-$version.pom; it does not recurse into mod1 mod2. (*) 3. 'mvn -pl apps/app1,apps/app1/mod1,apps/app1/mod2 -am' works (builds also lib1) but requires you on the command line to determine what the submodules of apps/app1 are. My own MNG-5059 [1] is a little related: the Maven CLI offers only limited options for building a set of modules. Perhaps there should be a DSL for selecting subsets of a reactor tree in various ways and building the subsets thus calculated to particular phases, all within a single CLI invocation. The old reactor:make could be revamped to do this, I guess, leaving M3's built-in options just for the simplest cases. (*) As Jason points out, existing systems may rely on an aggregator project passed to -pl being interpreted without recursion. In particular, NetBeans IDE priming builds rely on this behavior. [1] http://jira.codehaus.org/browse/MNG-5059 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Site Plugin 2 2.4 Released
The Maven team is pleased to announce the release of the Maven Site Plugin 2, version 2.4 The Maven Site Plugin is a plugin that generates a site for the current project. http://maven.apache.org/plugins/maven-site-plugin-2.4 You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version2.4/version /plugin Release Notes - Maven Site Plugin 2 - Version 2.4 Bug * [MSITE-600] site plugin 3.0 does not permit a child to fully override parent site deployment URL * [MSITE-593] Correction in the french localization * [MSITE-589] Invalid image assignation in html * [MSITE-585] site-deploy: empty deploy protocol when properties are used Improvement * [MSITE-541] add skip option for site:deploy New Feature * [MSITE-582] Make it possible to remove breadcrumbs in child projects again * [MSITE-367] add skip parameter for multimodule project Task * [MSITE-637] Upgrade to doxia-sitetools-1.3 * [MSITE-636] Upgrade to doxia-1.3 Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 1.5 Annotations for Mojo
On 04/27/2012 01:34 PM, Ansgar Konermann wrote: JFrog (the Artifactory guys) has already published a set of Java 1.5 annotations for mojo development, including a m-plugin-p extension to use them. Beware that (acc. to their documentation) the tool relies on APT, which is deprecated in JDK 6 and scheduled to be dropped from JDK 8. New code should use JSR 269. A processor can perform semantic validation, and can also actually generate plugin.xml; if registered in META-INF/services no special mojo or compiler plugin configuration is needed to activate this. Generating synthetic classes is also quite easy - no need to deal with bytecode, just Java source. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: discussion on MNG-4637 : -pl switch negates recursion into sub projects
On 27 April 2012 13:29, Jesse Glick jesse.gl...@oracle.com wrote: On 04/27/2012 01:39 PM, Hilco Wijbenga wrote: What about -am and -amd? -am does work together with -pl. Vincent's issue is that -pl must be given a full list of submodules; just passing an aggregator is not enough. For example, take top +- libs | +- lib1 | +- lib2 +- apps +- app1 | +- mod1 [lib1] | +- mod2 [] +- app2 +- mod1 [] +- mod2 [lib2] where top, libs, apps, app1, and app2 are aggregator projects. Now say you want to build the first application. What should you do? 1. 'cd apps/app1 mvn' will not work unless lib1 has been previously built; -am does not help. 2. 'mvn -pl apps/app1 -am' will just install app1-$version.pom; it does not recurse into mod1 mod2. (*) 3. 'mvn -pl apps/app1,apps/app1/mod1,apps/app1/mod2 -am' works (builds also lib1) but requires you on the command line to determine what the submodules of apps/app1 are. Great, thanks! That makes it a lot clearer. My own MNG-5059 [1] is a little related: the Maven CLI offers only limited options for building a set of modules. Perhaps there should be a DSL for selecting subsets of a reactor tree in various ways and building the subsets thus calculated to particular phases, all within a single CLI invocation. The old reactor:make could be revamped to do this, I guess, leaving M3's built-in options just for the simplest cases. I guess this could be part of Maven Shell? Actually, I've been working on a Maven extension that uses checksums to determine whether a particular project needs to be rebuilt (taking all its dependencies into account). We are currently using a Bash script for that purpose. It simply invokes Maven for each project that needs to be (re)built but, obviously, doing this from Maven directly is much easier, faster, and more reliable. (*) As Jason points out, existing systems may rely on an aggregator project passed to -pl being interpreted without recursion. In particular, NetBeans IDE priming builds rely on this behavior. [1] http://jira.codehaus.org/browse/MNG-5059 - 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] Apache Maven Compiler Plugin 2.4
Hi, I'd like to release Apache Maven Compiler Plugin 2.4. We fixed: 13 issues (http://s.apache.org/MCOMPILER-2.4) Staging repository: https://repository.apache.org/content/repositories/maven-008/ Staging site: http://maven.apache.org/plugins/maven-compiler-plugin-2.4 (wait sync). Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +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
[VOTE] Release Maven Site Plugin version 3.1
Hi, We solved 19 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16489 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repo: https://repository.apache.org/content/repositories/maven-009/ Staging site: http://maven.apache.org/plugins/maven-site-plugin-3.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Changes Plugin version 2.7
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. 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
Re: 1.5 Annotations for Mojo
Some of us are still on 2.0.x. I for one, don't see the need to introduce (the possibility of) annotation hell into what is an already well understood mechanism. -Chris On Sat, Apr 28, 2012 at 4:01 AM, Olivier Lamy ol...@apache.org wrote: I would prefer not be core change dependent. Some folks are still using 2.x
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: discussion on MNG-4637 : -pl switch negates recursion into sub projects
On Sat, Apr 28, 2012 at 7:04 AM, Hilco Wijbenga hilco.wijbe...@gmail.comwrote: Actually, I've been working on a Maven extension that uses checksums to determine whether a particular project needs to be rebuilt (taking all its dependencies into account). We are currently using a Bash script for that purpose. It simply invokes Maven for each project that needs to be (re)built but, obviously, doing this from Maven directly is much easier, faster, and more reliable. Use Hudson/Jenkins for this, that's what I use.
Re: discussion on MNG-4637 : -pl switch negates recursion into sub projects
On 27 April 2012 17:51, Chris Graham chrisgw...@gmail.com wrote: On Sat, Apr 28, 2012 at 7:04 AM, Hilco Wijbenga hilco.wijbe...@gmail.comwrote: Actually, I've been working on a Maven extension that uses checksums to determine whether a particular project needs to be rebuilt (taking all its dependencies into account). We are currently using a Bash script for that purpose. It simply invokes Maven for each project that needs to be (re)built but, obviously, doing this from Maven directly is much easier, faster, and more reliable. Use Hudson/Jenkins for this, that's what I use. This is for local development. The build server isn't in the picture yet. It would not be smart to have the build server skip parts of the build anyway. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: discussion on MNG-4637 : -pl switch negates recursion into sub projects
On Sat, Apr 28, 2012 at 11:06 AM, Hilco Wijbenga hilco.wijbe...@gmail.comwrote: On 27 April 2012 17:51, Chris Graham chrisgw...@gmail.com wrote: On Sat, Apr 28, 2012 at 7:04 AM, Hilco Wijbenga hilco.wijbe...@gmail.comwrote: Actually, I've been working on a Maven extension that uses checksums to determine whether a particular project needs to be rebuilt (taking all its dependencies into account). We are currently using a Bash script for that purpose. It simply invokes Maven for each project that needs to be (re)built but, obviously, doing this from Maven directly is much easier, faster, and more reliable. Use Hudson/Jenkins for this, that's what I use. This is for local development. The build server isn't in the picture yet. It would not be smart to have the build server skip parts of the build anyway. No, that's not true. If the project build resolution is deterministic, ie it will always result in the same build result. This is good or standard SCM practice. Jenkins fingerprinting (not that I've used that one much) or M2 job type (that I have almost always used) dependency analysis does exactly this. However, by definition, a release build, would (and should) result in a full build. -Chris
Re: [VOTE] Release Apache Maven SCM 1.7
+1 Hervé Le jeudi 26 avril 2012 18:23:13 Olivier Lamy a écrit : Hi, I'd like to release Apache Maven SCM 1.7. We fixed 18 issues ( http://s.apache.org/SCM-1.7 ) One new feature is the support of Jazz Scm (thanks to Chris Graham !) The staging repository is available here: https://repository.apache.org/content/repositories/maven-112/ The staging site: http://maven.apache.org/scm-1.7/ (the full content is not yet sync). [+1] [0] [-1] Vote open for 72H. Thanks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pushing plugin web site for release votes
for the moment, we didn't come to something yet what is missing is: 1. feedback about proposed procedure [1] 2. parent pom modification with m-site-scm-publish-p to match previous procedure 3. initial import help on 1 2 would be greatly appreciated And I'm looking into 3. Regards, Hervé [1] http://maventest.apache.org/developers/release/maven-plugin-release.html Le vendredi 27 avril 2012 09:27:12 Benson Margulies a écrit : I confess that I've been reading Hervé's emails with only half of an eye. Do I need to do anything CMS-y when staging a release of a plugin? - 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: 1.5 Annotations for Mojo
yes, +1 for the first step - ie annotations for plugin.xml generation but -0 for discovery with runtime annotation instead of plugin.xml and yes, I took time to document (end reference JFrog's implementation) but don't have really time to code it even if the feature would be a great benefit IMHO thenks for your work on that: I'll review and help Regards, Hervé Le vendredi 27 avril 2012 20:01:34 Olivier Lamy a écrit : I would prefer not be core change dependent. Some folks are still using 2.x . And 'classloader scanning' at runtime level will have IHMO a performance cost ! So I would prefer plugin metadata generation (the trick will be having the mix of doclet and annotations : perso I'm not sure it's a good idea to have both ? ) -- Olivier Send from a VT100 phone console Le 27 avr. 2012 18:26, Robert Scholte apa...@sourcegrounds.com a écrit : +100 I've had a talk about this with Simone this month. He'd done some investigation already. I think there are two separate steps to be taken. 1. Generate the plugin.xml based on both annotations and doclets 2. Extend Maven Core to understand Mojo Annotations as well The first one would already be a huge improvement for all mojo-devs. -Robert Op Fri, 27 Apr 2012 16:36:57 +0200 schreef Olivier Lamy ol...@apache.org Hi, I'd like to work on 1.5 Annotations for Mojos. Hervé started documentation here: https://cwiki.apache.org/**confluence/display/MAVEN/Java+** 5+Annotations+for+Pluginshttps://cwiki.apache.org/confluence/display/ MAVEN/Java+5+Annotations+for+Plugins The Stephen's idea for named without Mojo prefix looks fine (at least for me). But I would prefer to not implement (yet) the other idea with synthetic bridging classes. I can start the job next week (probably in a branch). Comments ? Thanks, --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: discussion on MNG-4637 : -pl switch negates recursion into sub projects
On 27 April 2012 18:20, Chris Graham chrisgw...@gmail.com wrote: On Sat, Apr 28, 2012 at 11:06 AM, Hilco Wijbenga hilco.wijbe...@gmail.comwrote: On 27 April 2012 17:51, Chris Graham chrisgw...@gmail.com wrote: On Sat, Apr 28, 2012 at 7:04 AM, Hilco Wijbenga hilco.wijbe...@gmail.comwrote: Actually, I've been working on a Maven extension that uses checksums to determine whether a particular project needs to be rebuilt (taking all its dependencies into account). We are currently using a Bash script for that purpose. It simply invokes Maven for each project that needs to be (re)built but, obviously, doing this from Maven directly is much easier, faster, and more reliable. Use Hudson/Jenkins for this, that's what I use. This is for local development. The build server isn't in the picture yet. It would not be smart to have the build server skip parts of the build anyway. No, that's not true. If the project build resolution is deterministic, ie it will always result in the same build result. This is good or standard SCM practice. What isn't true? You are not seriously suggesting we now do all local development via the build server, are you? That would be insanely inefficient. Not to mention the total chaos that would ensue. Local development is *local*, on your local machine, it hasn't reached anything or anyone else yet. I don't think we are talking about the same thing. :-) Or at least, I hope so. ;-) Jenkins fingerprinting (not that I've used that one much) or M2 job type (that I have almost always used) dependency analysis does exactly this. In my experience, Jenkins' dependency analysis only works if nothing (POM wise) has changed. As soon as you add/delete/move dependencies, it gets confused and builds things in the wrong order resulting in failed builds. Given that it doesn't know about all changes at the same time, this is not entirely unexpected, I suppose. But now we're veering off topic. :-) However, by definition, a release build, would (and should) result in a full build. -Chris - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
