UI for Group Actions
I'm looking at the UI for the new things in Group Actions, and there's some inconsistency. The drop down needs a space, Choose a Build Definition (not BuildDefinition). Everything else is capitalized, so the next one should be Build All Projects. We have Edit, Delete Group, and Release. Either they all need to have 'Group' or none of them should. (It's in a section called Group Actions, so leaving off Group is my preference. Shorter, too.) So far it seems clear that the drop downs go with the button just to the right, but I reserve the right to complain later if something else gets added. :) I'll eventually open issues for these if no one beats me to fixing them. It's going to be a busy week so I wanted to toss it out to see if anyone else has time. -- Wendy
Wrong icons immediately after adding projects
When I add a multi-module project, the project group summary shows the 'cancel build' icon for the first project, and 'queued build' icons for the rest. This is incorrect, nothing is building or queued at that time. If I navigate away and come back, it correctly shows the 'build project' icon for all of them. (This is in the 5th column from the right in r574073 built today.) -- Wendy
[VOTE] Release maven-one-plugin 1.2
Hi, I'd like to release maven-one-plugin 1.2. Release Notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11241styleName=Htmlversion=13531 Tag: https://svn.apache.org/repos/asf/maven/plugins/tags/maven-one-plugin-1.2/ Staged at: http://people.apache.org/~dennisl/staging-repository-one-plugin/ The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Path to 2.1-alpha-1
Hi, For the first set of alpha releases I think we should be focusing on fixing many of the problems and specifically dealing with: 1) Any backward compatibility problems 2) Error reporting and general usability issues 3) Regressions 4) Failing ITs (There are 11 commented out and one failing) 5) Bugs [1] We should be focused fixing these problems in the the first couple alphas, as we don't want to make a bad impression with the first releases, put early adopters through pain, and it would be irresponsible to start jamming in new features without addressing these issues first. Anyone who wants to refactor and fix bugs I say go for it on the trunk, new features should stay in branches until the proposals are all collected this friday and we slot features in for specific versions. If you want to fix any bugs then just slot assign it to a version and go for it. I think we should keep releasing alphas focusing on the issues above and start thinking about new features once they are under control. Otherwise this crap is just going to roll on and on. We need to decide that we are going to address the problems before tackling the fun new features. It's the only responsible way to continue I feel. [1] http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truefixfor=13142type=1pid=10500resolution=-1sorter/ field=prioritysorter/order=DESC Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
For anyone trying to fix configuration bugs in 2.1 (and some notes on how Maven 2.1 works)
Hi, I have made a great attempt to push all configuration of anything possible to configure in Maven to this class: http://svn.apache.org/repos/asf/maven/components/trunk/maven-embedder/ src/main/java/org/apache/maven/embedder/execution/ DefaultMavenExecutionRequestPopulator.java For anyone not familiar with the core in 2.1, we populate a MavenExecutionRequest and that is used in the MavenEmbedder.execute ( request ) method to carry out what you know Maven to do. The Maven CLI for 2.1.x uses the MavenEmbedder along with the IDE integration. The class above takes care of populating any defaults in the request before it is passed to the embedder. So if anyone is interested in trying to track down bugs with: - settings - profiles - update policies - checksum policies - wagon configurations: servers, proxies Then you can look in the request class and you will also want to look in the CLI class to see how the request is populated from command line options: http://svn.apache.org/repos/asf/maven/components/trunk/maven-embedder/ src/main/java/org/apache/maven/cli/MavenCli.java Between these two (at least for command line use) you should be able track down some of the easier configuration problems or bugs. There's still all sorts operations going on in the core like the merging of profiles, plugin configurations and what not, but the initial configuration is now all located in one place if anyone wants to take a shot of fixing anything here: http://jira.codehaus.org/secure/IssueNavigator.jspa? mode=hiderequestId=12412 Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath ordering of dependencies
It also sounds like perhaps you need an excludes in your dependency declaration, to get rid of that bad transitive dep. Wayne On 7 Sep 07, at 2:20 PM 7 Sep 07, Paul Gier wrote: I did a little more research, and it looks like the artifact was renamed, so maven didn't know they were the same artifact. For an example, if you create a project with a direct dependency on antlr:antlr:3.0b5 and have a transitive dependency on antlr:antlr: 2.7.1, you will get the 2.7.1 version in the classpath first because 3.0b5 has been renamed to groupId org.antlr When the groupId and artifactId are the same, then maven does the right thing and removed the transitive dependency. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Standard location for a plugin smoke test
Hi, Just doing some more planning for 2.1 and it would be very advantageous if we could harness many of the ITs created for plugins in a standard way so that we could run a build of Maven against as many plugins as we can get our hands on. I was thinking a standard directory location of a property in the POM pointing at the IT that should be used as the smoke test. We would also need a way to make a little attached artifact of this smoke test so that we have the smoke test for a particular release of a plugin for the future. I'm not sure how we would retrofit this but basically a standard way with a version of maven to test a version of a Maven plugin to make sure we haven't busted it's use. In particular I'm thinking of how to test 2.1 with all the plugins we know to exist and make sure they continue to work under 2.1. Any thoughts? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: code documentation was: For anyone trying to fix configuration bugs in 2.1 (and some notes on how Maven 2.1 works)
Cool. This mail has some good content that I'd like to retain in the code documentation. What process should we have for documenting code in Maven core? I kind of like: - as much as possible in the class javadoc that describes just that class (I think the current javadoc for MERP does this, and the rest of the mail could go into the MavenExecutionRequest javadoc) - package javadoc for things a whole package does - a couple of APTs for things the whole module does, tying the javadocs together with a more wholistic overview. WDYT? Cheers Brett On 10/09/2007, at 9:34 AM, Jason van Zyl wrote: Hi, I have made a great attempt to push all configuration of anything possible to configure in Maven to this class: http://svn.apache.org/repos/asf/maven/components/trunk/maven- embedder/src/main/java/org/apache/maven/embedder/execution/ DefaultMavenExecutionRequestPopulator.java For anyone not familiar with the core in 2.1, we populate a MavenExecutionRequest and that is used in the MavenEmbedder.execute ( request ) method to carry out what you know Maven to do. The Maven CLI for 2.1.x uses the MavenEmbedder along with the IDE integration. The class above takes care of populating any defaults in the request before it is passed to the embedder. So if anyone is interested in trying to track down bugs with: - settings - profiles - update policies - checksum policies - wagon configurations: servers, proxies Then you can look in the request class and you will also want to look in the CLI class to see how the request is populated from command line options: http://svn.apache.org/repos/asf/maven/components/trunk/maven- embedder/src/main/java/org/apache/maven/cli/MavenCli.java Between these two (at least for command line use) you should be able track down some of the easier configuration problems or bugs. There's still all sorts operations going on in the core like the merging of profiles, plugin configurations and what not, but the initial configuration is now all located in one place if anyone wants to take a shot of fixing anything here: http://jira.codehaus.org/secure/IssueNavigator.jspa? mode=hiderequestId=12412 Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Path to 2.1-alpha-1
On 10/09/2007, at 9:21 AM, Jason van Zyl wrote: Hi, For the first set of alpha releases I think we should be focusing on fixing many of the problems and specifically dealing with: 1) Any backward compatibility problems 2) Error reporting and general usability issues 3) Regressions 4) Failing ITs (There are 11 commented out and one failing) 5) Bugs [1] +1 We should be focused fixing these problems in the the first couple alphas, as we don't want to make a bad impression with the first releases, put early adopters through pain, and it would be irresponsible to start jamming in new features without addressing these issues first. Yep, though I'd say the first alpha only needs to take care of the things that make it more painful than using 2.0.x (ie, 1 and 3 - I'd say 4 but they all failed previously I think). Anyone who wants to refactor and fix bugs I say go for it on the trunk, new features should stay in branches until the proposals are all collected this friday and we slot features in for specific versions. If you want to fix any bugs then just slot assign it to a version and go for it. I agree with John, refactoring should be treated like features. I don't necessarily think in that case branches are a good idea (since it's difficult to merge), but I'd prefer to see proposals for anything further so people at least know the crossover with their own feature work. Otherwise, agreed. I think we should keep releasing alphas focusing on the issues above and start thinking about new features once they are under control. Otherwise this crap is just going to roll on and on. We need to decide that we are going to address the problems before tackling the fun new features. It's the only responsible way to continue I feel. [1] http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truefixfor=13142type=1pid=10500resolution=-1sorter/ field=prioritysorter/order=DESC Are all the known problems you refer to in that list? Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standard location for a plugin smoke test
Sorry, not quite grokking this - are you referring to setting up plugin ITs like the Maven core-its, but on a per-plugin basis? I think basically we want in each project: . `-- src `-- functional-tests |-- java `-- projects |-- test-project1 | |-- pom.xml | `-- src `-- test-project2 |-- pom.xml `-- src So, you have in java all the stuff like what we have in integration- tests, and then the test projects under projects that can be run independently (but don't verify themselves). I think this is pretty much consistent with the assembly plugin? Then in the parent project, we have a profile that enables this standard layout, and we probably need a way to configure them to run against either a particular Maven version (M2_HOME, forked), or using the embedder. This should allow assembling a test suite that can pull in plugins from multiple sources (like mojo.codehaus) that follow the same pattern. Is that sort of what you were thinking of? - Brett On 10/09/2007, at 11:59 AM, Jason van Zyl wrote: Hi, Just doing some more planning for 2.1 and it would be very advantageous if we could harness many of the ITs created for plugins in a standard way so that we could run a build of Maven against as many plugins as we can get our hands on. I was thinking a standard directory location of a property in the POM pointing at the IT that should be used as the smoke test. We would also need a way to make a little attached artifact of this smoke test so that we have the smoke test for a particular release of a plugin for the future. I'm not sure how we would retrofit this but basically a standard way with a version of maven to test a version of a Maven plugin to make sure we haven't busted it's use. In particular I'm thinking of how to test 2.1 with all the plugins we know to exist and make sure they continue to work under 2.1. Any thoughts? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Classpath ordering of dependencies
And you can use the enforcer noBannedDependency rule to make sure it doesn't come back. Take a look at the dependency plugin pom to see how I used it because the containerApi kept sneaking in. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Sunday, September 09, 2007 9:50 PM To: Maven Developers List Subject: Re: Classpath ordering of dependencies It also sounds like perhaps you need an excludes in your dependency declaration, to get rid of that bad transitive dep. Wayne On 7 Sep 07, at 2:20 PM 7 Sep 07, Paul Gier wrote: I did a little more research, and it looks like the artifact was renamed, so maven didn't know they were the same artifact. For an example, if you create a project with a direct dependency on antlr:antlr:3.0b5 and have a transitive dependency on antlr:antlr: 2.7.1, you will get the 2.7.1 version in the classpath first because 3.0b5 has been renamed to groupId org.antlr When the groupId and artifactId are the same, then maven does the right thing and removed the transitive dependency. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Standard location for a plugin smoke test
Presumably wouldn't this just mean building plugins/ with the latest candidate 2.1? If they don't already have Its, then they wouldn't be avail to port to this new location anyway so I'm not sure it makes a huge difference. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Sunday, September 09, 2007 10:00 PM To: Maven Developers List Subject: Standard location for a plugin smoke test Hi, Just doing some more planning for 2.1 and it would be very advantageous if we could harness many of the ITs created for plugins in a standard way so that we could run a build of Maven against as many plugins as we can get our hands on. I was thinking a standard directory location of a property in the POM pointing at the IT that should be used as the smoke test. We would also need a way to make a little attached artifact of this smoke test so that we have the smoke test for a particular release of a plugin for the future. I'm not sure how we would retrofit this but basically a standard way with a version of maven to test a version of a Maven plugin to make sure we haven't busted it's use. In particular I'm thinking of how to test 2.1 with all the plugins we know to exist and make sure they continue to work under 2.1. Any thoughts? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: code documentation was: For anyone trying to fix configuration bugs in 2.1 (and some notes on how Maven 2.1 works)
I would prefer the javadocs so it's self contained. Anyone looking at this detailed level would really want javadocs and not an APT anyway. The narrative description can go in the class javadoc to describe how/what/why etc. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, September 09, 2007 10:50 PM To: Maven Developers List Subject: Re: code documentation was: For anyone trying to fix configuration bugs in 2.1 (and some notes on how Maven 2.1 works) Cool. This mail has some good content that I'd like to retain in the code documentation. What process should we have for documenting code in Maven core? I kind of like: - as much as possible in the class javadoc that describes just that class (I think the current javadoc for MERP does this, and the rest of the mail could go into the MavenExecutionRequest javadoc) - package javadoc for things a whole package does - a couple of APTs for things the whole module does, tying the javadocs together with a more wholistic overview. WDYT? Cheers Brett On 10/09/2007, at 9:34 AM, Jason van Zyl wrote: Hi, I have made a great attempt to push all configuration of anything possible to configure in Maven to this class: http://svn.apache.org/repos/asf/maven/components/trunk/maven- embedder/src/main/java/org/apache/maven/embedder/execution/ DefaultMavenExecutionRequestPopulator.java For anyone not familiar with the core in 2.1, we populate a MavenExecutionRequest and that is used in the MavenEmbedder.execute ( request ) method to carry out what you know Maven to do. The Maven CLI for 2.1.x uses the MavenEmbedder along with the IDE integration. The class above takes care of populating any defaults in the request before it is passed to the embedder. So if anyone is interested in trying to track down bugs with: - settings - profiles - update policies - checksum policies - wagon configurations: servers, proxies Then you can look in the request class and you will also want to look in the CLI class to see how the request is populated from command line options: http://svn.apache.org/repos/asf/maven/components/trunk/maven- embedder/src/main/java/org/apache/maven/cli/MavenCli.java Between these two (at least for command line use) you should be able track down some of the easier configuration problems or bugs. There's still all sorts operations going on in the core like the merging of profiles, plugin configurations and what not, but the initial configuration is now all located in one place if anyone wants to take a shot of fixing anything here: http://jira.codehaus.org/secure/IssueNavigator.jspa? mode=hiderequestId=12412 Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] bring shade-maven-plugin to apache
The move is complete and the apache code is now in the
maven-sandbox/plugins/maven-shade-plugin.
The fate of the shade source at mojo is still pending but the votes so
far indicate it will be a full move. (removed from the mojo svn)
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Friday, September 07, 2007 7:39 PM
To: Maven Developers List
Cc: Maven Project Management Committee List
Subject: RE: [vote] bring shade-maven-plugin to apache
Results:
+7 (Binding) Brian, Jason, Brett, Stephane, Lukas, Dennis, Arnaud
+2 (Non Binding) Rafale, Andy,
This vote has passed. I will wrap up the move most likely over the
weekend. It will first go to the sandbox where we will perform the
refactoring of packages and to include apache headers.
Since I'm also a mojo committer, I'll call a vote over there to decide
what happens with the source in mojo.
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 02, 2007 10:37 PM
To: Maven Developers List
Subject: [vote] bring shade-maven-plugin to apache
The shade-maven-plugin is currently in the codehaus mojo sandbox. This
plugin is used by maven core to package the uberjar for distribution and
should be moved to the maven project.
Please vote {+1,0,-1], vote is open for 72 hrs.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standard location for a plugin smoke test
On 9 Sep 07, at 8:27 PM 9 Sep 07, Brian E. Fox wrote: Presumably wouldn't this just mean building plugins/ with the latest candidate 2.1? This would also be to check new versions of plugins with older versions of Maven. Knowing for certain and being able to test that the prereq is actually required or correct. It would allow to start doing some aggressive automated testing. If they don't already have Its, then they wouldn't be avail to port to this new location anyway so I'm not sure it makes a huge difference. Plugins that don't have ITs could simply have a standard configuration. I just want to validate a plugin functions as expected given a set of Maven versions. If we release a new version of the site plugin, making sure that it works for users who have 2.0.4 deployed for example. In my case for 2.1 I'm talking about validating that 2.1 still successfully runs all existing plugins. I need a place to hook into for a plugin is all I'm saying, and in the source tree wouldn't be good enough because I need the configuration that would be used for a particular release of the plugin. So maybe something equivalent to a little archetype that contains a smoke test for particular version of the site plugin, say. I make a new version of Maven, I grab the site plugin and all its released versions, for each version I have a smoke test packaged up that I can download run and validate the output. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Sunday, September 09, 2007 10:00 PM To: Maven Developers List Subject: Standard location for a plugin smoke test Hi, Just doing some more planning for 2.1 and it would be very advantageous if we could harness many of the ITs created for plugins in a standard way so that we could run a build of Maven against as many plugins as we can get our hands on. I was thinking a standard directory location of a property in the POM pointing at the IT that should be used as the smoke test. We would also need a way to make a little attached artifact of this smoke test so that we have the smoke test for a particular release of a plugin for the future. I'm not sure how we would retrofit this but basically a standard way with a version of maven to test a version of a Maven plugin to make sure we haven't busted it's use. In particular I'm thinking of how to test 2.1 with all the plugins we know to exist and make sure they continue to work under 2.1. Any thoughts? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standard location for a plugin smoke test
On 9 Sep 07, at 8:24 PM 9 Sep 07, Brett Porter wrote: Sorry, not quite grokking this - are you referring to setting up plugin ITs like the Maven core-its, but on a per-plugin basis? I think basically we want in each project: . `-- src `-- functional-tests |-- java `-- projects |-- test-project1 | |-- pom.xml | `-- src `-- test-project2 |-- pom.xml `-- src So, you have in java all the stuff like what we have in integration- tests, and then the test projects under projects that can be run independently (but don't verify themselves). I think this is pretty much consistent with the assembly plugin? Then in the parent project, we have a profile that enables this standard layout, and we probably need a way to configure them to run against either a particular Maven version (M2_HOME, forked), or using the embedder. This should allow assembling a test suite that can pull in plugins from multiple sources (like mojo.codehaus) that follow the same pattern. Is that sort of what you were thinking of? In addition the set of test would have to packaged up so that they could be retrieved for testing. For each release we will need the tests as they might change according to configuration or functionality changes in the plugin. I need a configuration of how that version of the plugin was used. It would most likely be an archetype that is created and deployed. How the matrix is execute will not be hard to do, but we need to start collecting the test projects and even retrofitting some plugins at least a couple versions back as this would be the only real way to validate 2.1 actually runs them so that we find the problems before users do. - Brett On 10/09/2007, at 11:59 AM, Jason van Zyl wrote: Hi, Just doing some more planning for 2.1 and it would be very advantageous if we could harness many of the ITs created for plugins in a standard way so that we could run a build of Maven against as many plugins as we can get our hands on. I was thinking a standard directory location of a property in the POM pointing at the IT that should be used as the smoke test. We would also need a way to make a little attached artifact of this smoke test so that we have the smoke test for a particular release of a plugin for the future. I'm not sure how we would retrofit this but basically a standard way with a version of maven to test a version of a Maven plugin to make sure we haven't busted it's use. In particular I'm thinking of how to test 2.1 with all the plugins we know to exist and make sure they continue to work under 2.1. Any thoughts? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-one-plugin 1.2
+1 On 10/09/2007, at 6:26 AM, Dennis Lundberg wrote: Hi, I'd like to release maven-one-plugin 1.2. Release Notes: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=11241styleName=Htmlversion=13531 Tag: https://svn.apache.org/repos/asf/maven/plugins/tags/maven-one- plugin-1.2/ Staged at: http://people.apache.org/~dennisl/staging-repository-one-plugin/ The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
