Re: [VOTE] Release Maven Release Plugin version 2.3
+1 the site problem seems like a sync issue: http://maven.apache.org/plugins/maven-release-plugin-2.3/css/ is empty, but p.a.o contains files I just touch-ed files to force a new sync, the site should be fixed in a couple of hours (without re-generating anything) Regards, Hervé Le mardi 8 mai 2012 00:15:21 Robert Scholte a écrit : Hi, I'd like to release the maven-release-plugin 2.3 We solved 22 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144version=183 34 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11144sta tus=1 Staging repo: https://repository.apache.org/content/repositories/maven-053/ Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.3/ (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, -Robert - 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 (binding) Just a small note: Please always also link to the source-release as this is what the ASF primarily ships. All other artifacts are only nice to have goodies (in the legal aspect). https://repository.apache.org/content/repositories/maven-053/org/apache/maven/release/maven-release/2.3/maven-release-2.3-source-release.zip LieGrue, strub - Original Message - From: Hervé BOUTEMY herve.bout...@free.fr To: Maven Developers List dev@maven.apache.org Cc: Sent: Thursday, May 10, 2012 8:06 AM Subject: Re: [VOTE] Release Maven Release Plugin version 2.3 +1 the site problem seems like a sync issue: http://maven.apache.org/plugins/maven-release-plugin-2.3/css/ is empty, but p.a.o contains files I just touch-ed files to force a new sync, the site should be fixed in a couple of hours (without re-generating anything) Regards, Hervé Le mardi 8 mai 2012 00:15:21 Robert Scholte a écrit : Hi, I'd like to release the maven-release-plugin 2.3 We solved 22 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144version=183 34 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11144sta tus=1 Staging repo: https://repository.apache.org/content/repositories/maven-053/ Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.3/ (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, -Robert - 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
I'm missing profiles.xml
Hi, just opening a several years old project, which was written for Maven 2 before 3.0 and is making heavy use of profiles.xml. Reminds me how much I am missing this feature: Local profiles used to be the most obvious, easiest to use place for local customizations like configuring a database URL or stuff like that. My own appreciation of Maven became significantly lower with the removal of that feature. Now, I am not asking to readd that feature, but I am wondering whether it wouldn't be possible to reintroduce it just for me by enabling a Maven extension or plugin that supports it. Any hints on how I could implement that? Thanks in advance, Jochen -- Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung. Dieter Hildebrandt - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: I'm missing profiles.xml
activation is king ;) The reason why it got removed is obvious: you needed to know exactly what goes into it. Without that info you sometimes could not even compile your project. What you can try nowadays is to create profiles (maybe in your parent pom) and have them activated via a system property. LieGrue, strub - Original Message - From: Jochen Wiedmann jochen.wiedm...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Thursday, May 10, 2012 9:40 AM Subject: I'm missing profiles.xml Hi, just opening a several years old project, which was written for Maven 2 before 3.0 and is making heavy use of profiles.xml. Reminds me how much I am missing this feature: Local profiles used to be the most obvious, easiest to use place for local customizations like configuring a database URL or stuff like that. My own appreciation of Maven became significantly lower with the removal of that feature. Now, I am not asking to readd that feature, but I am wondering whether it wouldn't be possible to reintroduce it just for me by enabling a Maven extension or plugin that supports it. Any hints on how I could implement that? Thanks in advance, Jochen -- Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung. Dieter Hildebrandt - 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 Remote Resource Plugin 1.3
Here my +1. 2012/5/7 Olivier Lamy ol...@apache.org: Hi, I'd like to release Maven Remote Resource Plugin 1.3. We fixed 4 issues: http://s.apache.org/MRRESOURCES-1.3 The staging repo: https://repository.apache.org/content/repositories/maven-052/ The site staging: http://maven.apache.org/plugins/maven-remote-resources-plugin-1.3 (wait 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 -- 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: I'm missing profiles.xml
On Thu, May 10, 2012 at 10:00 AM, Mark Struberg strub...@yahoo.de wrote: The reason why it got removed is obvious: you needed to know exactly what goes into it. Without that info you sometimes could not even compile your project. What you can try nowadays is to create profiles (maybe in your parent pom) and have them activated via a system property. Be that as it may, I still have uncompilable projects from time to time, only that I now have to define the same profiles in my settings.xml +(!) activate them locally. Jochen -- Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung. Dieter Hildebrandt - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
Sorry to hear that you have no fun hacking here anymore. But just to share some thoughts about the groovy-maven stuff. I can certainly see that there was lots of bad timing around on both sides in those days. But the argument for _not_ checking this in to maven 1:1 was mainly because this feature a.) doesn't really fit 100% with the declarative approach of maven but is more the old 'imperative' one. The very explicit idea was always to only do imperative tasks in plugins and _not_ in a normal project description. b.) it imo doesn't work out to throw 2 years of outside work onto a COMMUNITY which had no way to make any decisions but should rather 'take it as is or leave it'. This stuff is fairly complex and has lots of dependencies and impact. It would have been needed to do a complete IP sanity check, check all the projects history, identify and rewrite all outside contributions, review the used pattern, build some community, etc etc. I don't like to stress that there would have been better ways to improve maven in this direction, because we all know that there is not always the perfect time for this stuff. Afair our response was exactly that: we would need much more time to incorporate this properly and we will for sure _not_ pull this stuff in 1:1 before we have a detailed clue what it does. You also don't eat stuff where you have no clue what is in it, right? LieGrue, strub - Original Message - From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org Cc: Sent: Thursday, May 10, 2012 1:15 AM Subject: Re: Plugins with Annotations ETA On May 9, 2012, at 3:30 PM, Mark Derricutt wrote: On 10/05/12 7:47 AM, Jason van Zyl wrote: The only thing I would like to sync up on is a couple changes I want to make to the plugin manager to make sure the current plugin packaging, the plugin packaging you're making and the plugin packaging I'm working on in Tesla all work together without conflicting. Anyone should theoretically be able to make a toolchain and allow users to take Is there any intent to merge any of the etesla stuff back into Apache Maven core at all? ( I'd really love to see Atom POM in some 'official blessed' manner ). I plan to do the odd patch and help with extensibility for what I would like to do in Tesla, but as far as merging the work no plans. Apache nearly expunged all my passion for innovating and doing open source in general. I've been happy again lately hacking with folks like Dhanji and I personally don't plan to contribute anything significant to Apache ever again. I speak here purely for myself. The overhead for innovating at Apache is just too high for me. Maven has stagnated and I believe that's fairly visible to most users and I can't really do anything about that from Apache. But I can from Tesla, and I've enjoyed how Tesla has gone and I plan to continue working this way. I'm having fun again and I can contribute to the ecosystem when I enjoy what I'm doing. As far as Tesla goes and how it relates to builds it is a set of add-ons to Maven. I have a couple small patches for the core to contribute back, but if you want to take advantage of build stuff in Tesla it's just adding some JARs to the distribution. But Tesla is not only about builds. I am building integration across the build, IDE, repository manager, CI, provisioning and software delivery in general. My work now I would categorize as being interested in the continuity across all the tools and the build is a small part of that. I can move faster working by myself and selectively working with folks like Dhanji, Dain and Jeanfrancois. The core of Maven has been modified to the point where it is fully extensible purely by the addition of JARs. Further to that Igor has created a mechanism that allows extension by configuration so that upon startup Maven can alter its functionality by downloading new extensions on the fly. This Sonatype is likely to contribute back and once that is done anyone should be able to extend Maven easily whether it be for individual use or for thousands of developers within a corporation. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: I'm missing profiles.xml
I only have those profiles in my projects. The only profile I have in my settings.xml is for enabling staging repos. Do you have a sample so we get an idea what you try to solve? LieGrue, strub - Original Message - From: Jochen Wiedmann jochen.wiedm...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Thursday, May 10, 2012 10:37 AM Subject: Re: I'm missing profiles.xml On Thu, May 10, 2012 at 10:00 AM, Mark Struberg strub...@yahoo.de wrote: The reason why it got removed is obvious: you needed to know exactly what goes into it. Without that info you sometimes could not even compile your project. What you can try nowadays is to create profiles (maybe in your parent pom) and have them activated via a system property. Be that as it may, I still have uncompilable projects from time to time, only that I now have to define the same profiles in my settings.xml +(!) activate them locally. Jochen -- Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung. Dieter Hildebrandt - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: I'm missing profiles.xml
On Thu, May 10, 2012 at 10:41 AM, Mark Struberg strub...@yahoo.de wrote: I only have those profiles in my projects. The only profile I have in my settings.xml is for enabling staging repos. Do you have a sample so we get an idea what you try to solve? Mark, you're getting me wrong. I am not trying to discussing the decision to remove profiles. I am simply asking for help in getting them working again here. What I do is quite simple: My test suite is accessing a database. And the JDBC URL is specified in a property, which was previously defined in a profiles.xml file. That worked very well and has been understood and appreciated by all colleagues. Which is no longer the case with the move to settings.xml. Jochen -- Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung. Dieter Hildebrandt - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
On 05/09/2012 12:56 PM, Olivier Lamy wrote: we still need to do some javadoc parsing for @deprecated Just look for @Deprecated - the real annotation - instead. (Note that javac will warn you if you have the Javadoc tag without the annotation.) @since and comments for class/field description. So if annotations comes from reactor module (easy to scan sources) but if comes from a dependency I try to get the sources from the artifact with try to resolve the same artifact with classifier sources. Would be simpler to define true annotations (marked @Documented) for the things you use, e.g. @Since or @Description. Then there is no need to look for sources of binary dependencies, and no need to parse them. You are also insulated against Java language changes, and can interoperate properly with other JVM languages compatible with JSR 175. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven Remote Resource Plugin 1.3
+1 Hervé Le lundi 7 mai 2012 22:23:20 Olivier Lamy a écrit : Hi, I'd like to release Maven Remote Resource Plugin 1.3. We fixed 4 issues: http://s.apache.org/MRRESOURCES-1.3 The staging repo: https://repository.apache.org/content/repositories/maven-052/ The site staging: http://maven.apache.org/plugins/maven-remote-resources-plugin-1.3 (wait 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: [VOTE] Release Maven Enforcer version 1.1
+1 Hervé Le mardi 8 mai 2012 22:46:26 Paul Gier a écrit : Hi, We solved 5 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=17 443 There are still a couple of issues left in JIRA: https://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=pro ject+%3D+MENFORCER+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-058/ Staging site: http://maven.apache.org/enforcer-1.1/ http://maven.apache.org/plugins/maven-enforcer-plugin-1.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
Re: Plugins with Annotations ETA
2012/5/10 Jesse Glick jesse.gl...@oracle.com: On 05/09/2012 12:56 PM, Olivier Lamy wrote: we still need to do some javadoc parsing for @deprecated Just look for @Deprecated - the real annotation - instead. (Note that javac will warn you if you have the Javadoc tag without the annotation.) @since and comments for class/field description. So if annotations comes from reactor module (easy to scan sources) but if comes from a dependency I try to get the sources from the artifact with try to resolve the same artifact with classifier sources. Would be simpler to define true annotations (marked @Documented) for the things you use, e.g. @Since or @Description. Then there is no need to look for sources of binary dependencies, and no need to parse them. You are also insulated against Java language changes, and can interoperate properly with other JVM languages compatible with JSR 175. I have this idea first too using only annotations but I don't have text in this anno @Deprecated(because bla bla) Agree on @Since, @Description looks nice but I found a bit ugly something like @Description( The role names of mojo extractors to use. If not set, all mojo extractors will be used. If set to an empty extractor name, no mojo extractors will be used. Example: !-- Use all mojo extractors -- extractors/ !-- Use no mojo extractors -- extractors extractor/ /extractors !-- Use only bsh mojo extractor -- extractors extractorbsh/extractor /extractors ) And furthermore published javadoc won't as nice as today :-) Others ? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Release Plugin version 2.3
+1 Op Thu, 10 May 2012 08:54:27 +0200 schreef Mark Struberg strub...@yahoo.de: +1 (binding) Just a small note: Please always also link to the source-release as this is what the ASF primarily ships. All other artifacts are only nice to have goodies (in the legal aspect). https://repository.apache.org/content/repositories/maven-053/org/apache/maven/release/maven-release/2.3/maven-release-2.3-source-release.zip LieGrue, strub - Original Message - From: Hervé BOUTEMY herve.bout...@free.fr To: Maven Developers List dev@maven.apache.org Cc: Sent: Thursday, May 10, 2012 8:06 AM Subject: Re: [VOTE] Release Maven Release Plugin version 2.3 +1 the site problem seems like a sync issue: http://maven.apache.org/plugins/maven-release-plugin-2.3/css/ is empty, but p.a.o contains files I just touch-ed files to force a new sync, the site should be fixed in a couple of hours (without re-generating anything) Regards, Hervé Le mardi 8 mai 2012 00:15:21 Robert Scholte a écrit : Hi, I'd like to release the maven-release-plugin 2.3 We solved 22 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144version=183 34 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11144sta tus=1 Staging repo: https://repository.apache.org/content/repositories/maven-053/ Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.3/ (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, -Robert - 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: Plugins with Annotations ETA
@java.lang.Deprecated misses not only the description text but also a 'since' field. It would be really important to know since when a method is deprecated... LieGrue, strub - Original Message - From: Olivier Lamy ol...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Thursday, May 10, 2012 9:34 PM Subject: Re: Plugins with Annotations ETA 2012/5/10 Jesse Glick jesse.gl...@oracle.com: On 05/09/2012 12:56 PM, Olivier Lamy wrote: we still need to do some javadoc parsing for @deprecated Just look for @Deprecated - the real annotation - instead. (Note that javac will warn you if you have the Javadoc tag without the annotation.) @since and comments for class/field description. So if annotations comes from reactor module (easy to scan sources) but if comes from a dependency I try to get the sources from the artifact with try to resolve the same artifact with classifier sources. Would be simpler to define true annotations (marked @Documented) for the things you use, e.g. @Since or @Description. Then there is no need to look for sources of binary dependencies, and no need to parse them. You are also insulated against Java language changes, and can interoperate properly with other JVM languages compatible with JSR 175. I have this idea first too using only annotations but I don't have text in this anno @Deprecated(because bla bla) Agree on @Since, @Description looks nice but I found a bit ugly something like @Description( The role names of mojo extractors to use. If not set, all mojo extractors will be used. If set to an empty extractor name, no mojo extractors will be used. Example: !-- Use all mojo extractors -- extractors/ !-- Use no mojo extractors -- extractors extractor/ /extractors !-- Use only bsh mojo extractor -- extractors extractorbsh/extractor /extractors ) And furthermore published javadoc won't as nice as today :-) Others ? - 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
[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
[RESULT] [VOTE] Release Maven Release Plugin version 2.3
Hi, The vote has passed with the following result : +1 (binding): Olivier Lamy, Hervé Boutemy, Mark Struberg, Robert Scholte +1 (non binding): Laird Nelson, Chris Graham, Mirko Friedenhagen I will promote the artifacts to the central repo. Thanks for the votes! Robert Scholte - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Release Maven Release Plugin version 2.3
Hi, Some final notes: @Laird, thanks, this is indeed one of the most important fixes. @Chris, as you might have noticed you have a non-binding vote. Every feedback is appreciated. @Hervé, thanks for fixing the site as mentioned by Mirko. @Mark, I've adjusted the VOTE-template for the next time. -Robert Op Fri, 11 May 2012 00:17:30 +0200 schreef Robert Scholte apa...@sourcegrounds.com: Hi, The vote has passed with the following result : +1 (binding): Olivier Lamy, Hervé Boutemy, Mark Struberg, Robert Scholte +1 (non binding): Laird Nelson, Chris Graham, Mirko Friedenhagen I will promote the artifacts to the central repo. Thanks for the votes! Robert Scholte - 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: [RESULT] [VOTE] Release Maven Release Plugin version 2.3
I did notice that! Thanks! And thanks to everyone for helping me get my first (hopefully of many) contributions through to the process! -Chris Sent from my iPhone On 11/05/2012, at 8:26 AM, Robert Scholte apa...@sourcegrounds.com wrote: Hi, Some final notes: @Laird, thanks, this is indeed one of the most important fixes. @Chris, as you might have noticed you have a non-binding vote. Every feedback is appreciated. @Hervé, thanks for fixing the site as mentioned by Mirko. @Mark, I've adjusted the VOTE-template for the next time. -Robert Op Fri, 11 May 2012 00:17:30 +0200 schreef Robert Scholte apa...@sourcegrounds.com: Hi, The vote has passed with the following result : +1 (binding): Olivier Lamy, Hervé Boutemy, Mark Struberg, Robert Scholte +1 (non binding): Laird Nelson, Chris Graham, Mirko Friedenhagen I will promote the artifacts to the central repo. Thanks for the votes! Robert Scholte - 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
[jira] Subscription: Design Best Practices
Issue Subscription
Filter: Design Best Practices (25 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
https://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
https://jira.codehaus.org/browse/MNG-612
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-4656Declarative plugins similar to jsp tags or jsf composites
https://jira.codehaus.org/browse/MNG-4656
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-5277best practices: The Maven Way
https://jira.codehaus.org/browse/MNG-5277
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-868 Use uniform format for properties and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
https://jira.codehaus.org/browse/MNG-1569
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven Remote Resource Plugin 1.3
Ping. -- Olivier Le 7 mai 2012 22:23, Olivier Lamy ol...@apache.org a écrit : Hi, I'd like to release Maven Remote Resource Plugin 1.3. We fixed 4 issues: http://s.apache.org/MRRESOURCES-1.3 The staging repo: https://repository.apache.org/content/repositories/maven-052/ The site staging: http://maven.apache.org/plugins/maven-remote-resources-plugin-1.3 (wait 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
