Re: svn commit: r784555 - /maven/components/branches/maven-2.1.x/maven-core/pom.xml
Hi, I think the only committer will have a look at this :-) But the main issue will be to have the svnkit version available in central repo. Thanks, -- Olivier 2009/7/1 Brett Porter br...@apache.org: On 01/07/2009, at 4:53 AM, Benjamin Bentmann wrote: Brett Porter wrote: [INFO] Cannot get the revision information from the scm repository : Exception while executing SCM command. svn: '/Users/brett/scm/maven/maven-2.1.x/maven-core' is not a working copy OK, as the javasvn provider seems not to work as reliable as the regular svn provider, I reverted my change. Independently from the updates we discussed here, I suggest you fill an issue at the javasvn project. http://code.google.com/p/maven-scm-provider-svnjava/issues/detail?id=4 Benjamin - 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: svn commit: r784555 - /maven/components/branches/maven-2.1.x/maven-core/pom.xml
to have the svnkit version available in central repo. afaik there is a problem with the svnkit license [1] which seems not compatible to ASL because it requires loyalties if used commercially (even if not used directly but as part of e.g. maven). So there is no legal way to switch to svnkit as a default implementation not to put it on repo.apache.org. LieGrue, strub [1] http://svnkit.com/licensing.html --- Olivier Lamy ol...@apache.org schrieb am Mi, 1.7.2009: Von: Olivier Lamy ol...@apache.org Betreff: Re: svn commit: r784555 - /maven/components/branches/maven-2.1.x/maven-core/pom.xml An: Maven Developers List dev@maven.apache.org Datum: Mittwoch, 1. Juli 2009, 8:58 Hi, I think the only committer will have a look at this :-) But the main issue will be to have the svnkit version available in central repo. Thanks, -- Olivier 2009/7/1 Brett Porter br...@apache.org: On 01/07/2009, at 4:53 AM, Benjamin Bentmann wrote: Brett Porter wrote: [INFO] Cannot get the revision information from the scm repository : Exception while executing SCM command. svn: '/Users/brett/scm/maven/maven-2.1.x/maven-core' is not a working copy OK, as the javasvn provider seems not to work as reliable as the regular svn provider, I reverted my change. Independently from the updates we discussed here, I suggest you fill an issue at the javasvn project. http://code.google.com/p/maven-scm-provider-svnjava/issues/detail?id=4 Benjamin - 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: Maven 2.2.0 Release work to do
I left the src artifact in place mainly because I misunderstood where it was coming from. I figured it was generated from the source-jar goal, not from an assembly descriptor...wasn't thinking too deeply about it, just assumed we weren't compliant with the recent thread on voting sources vs. binaries. I did send the announcement to annou...@maven and us...@maven, I'll replay it to annou...@asf. Thanks for working on the JIRA maintenance stuff. I got completely buried in looking for 2.1.0 reference in the site sources yesterday, and lost track of some things obviously. This core release process is incredibly difficult to get right, so it would be good to have it at least documented. Brett Porter wrote: Hi, John, do you want to do the honours in sending the announce@ / annou...@maven / us...@maven mail to announce the release? For the record, these are the other things I picked up today. I'll look at making sure we have this all documented for the future: - uploaded the files to www.apache.org/dist - some straggling references in the site to the wrong release notes, etc. - released JIRA version - archived some old JIRA versions (3.0-alpha-1, 2.1.0-M1, 2.0.5 due to age) - removed old binaries / sources from www.apache.org/dist (they remain in archive.apache.org) Note there was also a problem with the source release in the repository - there were two (source-release and src). I didn't notice that in the vote. The only difference is LICENSE and NOTICE, which are incorrect in source-release. I'm going to remove that descriptor. - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
I'm -0 on the 2.0.11 release. On Tue, Jun 30, 2009 at 11:10 PM, Brett Porterbr...@apache.org wrote: On 01/07/2009, at 6:01 AM, Brian Fox wrote: On Tue, Jun 30, 2009 at 11:58 AM, Brett Porterbr...@apache.org wrote: On 01/07/2009, at 1:47 AM, nicolas de loof wrote: I'm also fine with this, just would like to avoid some EOL tag on 2.0 that may be considered as lack of support by some corporate users using (old) maven releases Sure, we can use a different name. All I meant EOL to mean here was that we don't plan to make any more releases (unless something is found to be really, horribly, wrong). EOD (end of development) is probably more appropriate. Exactly, and IMO, we're at that point today with 2.0.10 Ok, but are you leaning towards a -0 or a -1 on a 2.0.11 release? I'm happy to burn the small amount of my time on it and clean up the release process along the way (given the issues we had with 2.2.0). I'm not looking to add any more changes, just release the 37 already merged in there so we have a proper end point. It should be a short cycle since it's stuff already in 2.1.0+, but there were a couple of critical ones (eg, POM plugin ordering regression) that are worth having IMO. Cheers, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-toolchains-plugin
I think you were the last to work on it ;-) so you're probably most qualified to answer that and/or do the release. On Tue, Jun 30, 2009 at 11:04 PM, Shane Isbellshane.isb...@gmail.com wrote: I'm wondering if there are any plans to release the maven-toolchains-plugin . It looks like it's still as a 1.0-snapshot. I've got a need for maven-toolchain and don't want to duplicate the plugin. Thanks, Shane - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
Brian Fox wrote: Yeah get rid of it. Is there really demand for the fixed in 2.0.11? I feel like it's EOL now. The point is, in 6 months nobody knows axaclty anymore what is in 2.0.11-SNAPSHOT. That will actually stop any bugfix release ever. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
My preference is to release 2.0.11 as it is now (37 issues fixed). The remaining issues should move to 2.2.1. If critical bugs remain in 2.0.x, then build build a 2.0.12 issue list as people require it. - Paul On Wed, Jul 1, 2009 at 10:33 AM, Jörg Schaiblejoerg.schai...@gmx.de wrote: Brian Fox wrote: Yeah get rid of it. Is there really demand for the fixed in 2.0.11? I feel like it's EOL now. The point is, in 6 months nobody knows axaclty anymore what is in 2.0.11-SNAPSHOT. That will actually stop any bugfix release ever. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
+1 Paul Benedict wrote: My preference is to release 2.0.11 as it is now (37 issues fixed). The remaining issues should move to 2.2.1. If critical bugs remain in 2.0.x, then build build a 2.0.12 issue list as people require it. - Paul On Wed, Jul 1, 2009 at 10:33 AM, Jörg Schaiblejoerg.schai...@gmx.de wrote: Brian Fox wrote: Yeah get rid of it. Is there really demand for the fixed in 2.0.11? I feel like it's EOL now. The point is, in 6 months nobody knows axaclty anymore what is in 2.0.11-SNAPSHOT. That will actually stop any bugfix release ever. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
Paul Benedict schrieb: My preference is to release 2.0.11 as it is now (37 issues fixed). The remaining issues should move to 2.2.1. If critical bugs remain in 2.0.x, then build build a 2.0.12 issue list as people require it. - Paul +1 2.0.x is the last JDK 1.4 release. Users of the GPG plugin simply cannot use 2.1.x. -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
Ok, for starters I've moved all the open issues from 2.0.11 to 2.2.1 and am now going through them to cull them down where possible. I've also confirmed that the ITs pass for 2.0.11-SNAPSHOT as it is. Once I get the 2.1.x bits cleaned up (per original mail that everyone seems in favour of), I'll spin an RC and see what everyone thinks. - Brett On 02/07/2009, at 1:46 AM, John Casey wrote: +1 Paul Benedict wrote: My preference is to release 2.0.11 as it is now (37 issues fixed). The remaining issues should move to 2.2.1. If critical bugs remain in 2.0.x, then build build a 2.0.12 issue list as people require it. - Paul On Wed, Jul 1, 2009 at 10:33 AM, Jörg Schaiblejoerg.schai...@gmx.de wrote: Brian Fox wrote: Yeah get rid of it. Is there really demand for the fixed in 2.0.11? I feel like it's EOL now. The point is, in 6 months nobody knows axaclty anymore what is in 2.0.11-SNAPSHOT. That will actually stop any bugfix release ever. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
On 1-Jul-09, at 9:47 AM, Brett Porter wrote: Ok, for starters I've moved all the open issues from 2.0.11 to 2.2.1 and am now going through them to cull them down where possible. You need to leave the bugs raised against 2.0.x because there is no way around the fact that 2.0.x is going to be the dominant version used for quite some time. We can't just stop bug fixing the 2.0.x line. If you moved them all how are you going to know what applies? I've also confirmed that the ITs pass for 2.0.11-SNAPSHOT as it is. Once I get the 2.1.x bits cleaned up (per original mail that everyone seems in favour of), I'll spin an RC and see what everyone thinks. - Brett On 02/07/2009, at 1:46 AM, John Casey wrote: +1 Paul Benedict wrote: My preference is to release 2.0.11 as it is now (37 issues fixed). The remaining issues should move to 2.2.1. If critical bugs remain in 2.0.x, then build build a 2.0.12 issue list as people require it. - Paul On Wed, Jul 1, 2009 at 10:33 AM, Jörg Schaiblejoerg.schai...@gmx.de wrote: Brian Fox wrote: Yeah get rid of it. Is there really demand for the fixed in 2.0.11? I feel like it's EOL now. The point is, in 6 months nobody knows axaclty anymore what is in 2.0.11-SNAPSHOT. That will actually stop any bugfix release ever. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
On 02/07/2009, at 3:38 AM, Jason van Zyl wrote: On 1-Jul-09, at 9:47 AM, Brett Porter wrote: Ok, for starters I've moved all the open issues from 2.0.11 to 2.2.1 and am now going through them to cull them down where possible. You need to leave the bugs raised against 2.0.x because there is no way around the fact that 2.0.x is going to be the dominant version used for quite some time. We can't just stop bug fixing the 2.0.x line. If you moved them all how are you going to know what applies? There weren't any changes to the affects version. - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
It's logical to believe that 2.1 and 2.2 contain almost all the unresolved bugs of 2.0.x. Since 2.0.x is no longer being supported, there's no good reason to keep them attached to that version. You only want to backport the issues that will get fixing -- not potential fixes UNLESS the issue is exclusively a 2.0.x issue. -- Paul On Wed, Jul 1, 2009 at 12:38 PM, Jason van Zyljvan...@sonatype.com wrote: You need to leave the bugs raised against 2.0.x because there is no way around the fact that 2.0.x is going to be the dominant version used for quite some time. We can't just stop bug fixing the 2.0.x line. If you moved them all how are you going to know what applies? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
Christian Schulte wrote: Paul Benedict schrieb: My preference is to release 2.0.11 as it is now (37 issues fixed). The remaining issues should move to 2.2.1. If critical bugs remain in 2.0.x, then build build a 2.0.12 issue list as people require it. - Paul +1 2.0.x is the last JDK 1.4 release. Users of the GPG plugin simply cannot use 2.1.x. No. 2.1.x is also JDK 1.4. That was the whole point for starting 2.2.x. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
On 1-Jul-09, at 10:52 AM, Paul Benedict wrote: It's logical to believe that 2.1 and 2.2 contain almost all the unresolved bugs of 2.0.x. Since 2.0.x is no longer being supported, there's no good reason to keep them attached to that version. You only want to backport the issues that will get fixing -- not potential fixes UNLESS the issue is exclusively a 2.0.x issue. Unfortunately this may not be the case because the code bases are now pretty different. My only concern is that the 2.0.x line becomes the ugly stepchild meanwhile this is where the vast majority of our users live. -- Paul On Wed, Jul 1, 2009 at 12:38 PM, Jason van Zyljvan...@sonatype.com wrote: You need to leave the bugs raised against 2.0.x because there is no way around the fact that 2.0.x is going to be the dominant version used for quite some time. We can't just stop bug fixing the 2.0.x line. If you moved them all how are you going to know what applies? - 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 http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
FYI, you can still build 1.4 projects safely in Maven 2.2.0: http://maven.apache.org/guides/mini/guide-building-jdk14-on-jdk15.html -john Christian Schulte wrote: Paul Benedict schrieb: My preference is to release 2.0.11 as it is now (37 issues fixed). The remaining issues should move to 2.2.1. If critical bugs remain in 2.0.x, then build build a 2.0.12 issue list as people require it. - Paul +1 2.0.x is the last JDK 1.4 release. Users of the GPG plugin simply cannot use 2.1.x. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
On 02/07/2009, at 4:06 AM, Jason van Zyl wrote: On 1-Jul-09, at 10:52 AM, Paul Benedict wrote: It's logical to believe that 2.1 and 2.2 contain almost all the unresolved bugs of 2.0.x. Since 2.0.x is no longer being supported, there's no good reason to keep them attached to that version. You only want to backport the issues that will get fixing -- not potential fixes UNLESS the issue is exclusively a 2.0.x issue. Unfortunately this may not be the case because the code bases are now pretty different. My only concern is that the 2.0.x line becomes the ugly stepchild meanwhile this is where the vast majority of our users live. Ok, even so - I think there was some agreement that we wouldn't explicitly plan for a 2.0.12+ release, which was the motivation for the change I made. If, in the process of fixing an issue, the committer decides it really should be backported to 2.0.x that's still a possibility (or if someone else comes along and requests it). But I get the feeling that those sticking to 2.0.x are happy - in that they've got things working the way they want and probably won't jump up to further 2.0.x releases, let along 2.2.x. If we put out a 2.0.11 release and say this is the last, barring critical issues - start looking at 2.2, we'll fairly soon hear about it if that's not what users want. At the same time, if we do start pushing fixes into 2.2.x, that gives more people incentive to try it, and help us identify if there are further barriers to moving across, in addition to continuing to build out more integration test cases that benefit us across the board. - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
Brett Porter wrote: But I get the feeling that those sticking to 2.0.x are happy - in that they've got things working the way they want and probably won't jump up to further 2.0.x releases, let along 2.2.x. If we put out a 2.0.11 release and say this is the last, barring critical issues - start looking at 2.2, we'll fairly soon hear about it if that's not what users want. At the same time, if we do start pushing fixes into 2.2.x, that gives more people incentive to try it, and help us identify if there are further barriers to moving across, in addition to continuing to build out more integration test cases that benefit us across the board. - Brett Personally, I think this makes a lot of sense. I think we shouldn't go out of our way to freak out our user base, but at the same time we shouldn't spend too much time pushing the envelope with 2.0.x now that we've decided to move on. If we announce that we're doing critical fixes only on 2.0.x - and not spending time cleaning up - then people who have a problem with this should become visible. It's a good way to engage with our community to figure out why people won't make the jump, IMO. If it's just about an arbitrary version number, I'm not sure how to reassure those people without making a largely symbolic 2.2.1 release. -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
Jason, I apologize for misspeaking. I meant what Brian said: the affected version should stay the same. It's okay to remove the Fix for version which was altered to 2.2.1 On Wed, Jul 1, 2009 at 1:29 PM, Brett Porterbr...@apache.org wrote: On 02/07/2009, at 4:06 AM, Jason van Zyl wrote: On 1-Jul-09, at 10:52 AM, Paul Benedict wrote: It's logical to believe that 2.1 and 2.2 contain almost all the unresolved bugs of 2.0.x. Since 2.0.x is no longer being supported, there's no good reason to keep them attached to that version. You only want to backport the issues that will get fixing -- not potential fixes UNLESS the issue is exclusively a 2.0.x issue. Unfortunately this may not be the case because the code bases are now pretty different. My only concern is that the 2.0.x line becomes the ugly stepchild meanwhile this is where the vast majority of our users live. Ok, even so - I think there was some agreement that we wouldn't explicitly plan for a 2.0.12+ release, which was the motivation for the change I made. If, in the process of fixing an issue, the committer decides it really should be backported to 2.0.x that's still a possibility (or if someone else comes along and requests it). But I get the feeling that those sticking to 2.0.x are happy - in that they've got things working the way they want and probably won't jump up to further 2.0.x releases, let along 2.2.x. If we put out a 2.0.11 release and say this is the last, barring critical issues - start looking at 2.2, we'll fairly soon hear about it if that's not what users want. At the same time, if we do start pushing fixes into 2.2.x, that gives more people incentive to try it, and help us identify if there are further barriers to moving across, in addition to continuing to build out more integration test cases that benefit us across the board. - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: proposal for cleaning up 2.x series releases / trees
As a user... +1 On Jul 1, 2009, at 3:41 PM, John Casey wrote: Brett Porter wrote: But I get the feeling that those sticking to 2.0.x are happy - in that they've got things working the way they want and probably won't jump up to further 2.0.x releases, let along 2.2.x. If we put out a 2.0.11 release and say this is the last, barring critical issues - start looking at 2.2, we'll fairly soon hear about it if that's not what users want. At the same time, if we do start pushing fixes into 2.2.x, that gives more people incentive to try it, and help us identify if there are further barriers to moving across, in addition to continuing to build out more integration test cases that benefit us across the board. - Brett Personally, I think this makes a lot of sense. I think we shouldn't go out of our way to freak out our user base, but at the same time we shouldn't spend too much time pushing the envelope with 2.0.x now that we've decided to move on. If we announce that we're doing critical fixes only on 2.0.x - and not spending time cleaning up - then people who have a problem with this should become visible. It's a good way to engage with our community to figure out why people won't make the jump, IMO. If it's just about an arbitrary version number, I'm not sure how to reassure those people without making a largely symbolic 2.2.1 release. -john - 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 Christian Edward Gruber christianedwardgru...@gmail.com http://www.geekinasuit.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r789993 - in /maven/components/trunk/maven-core/src: main/java/org/apache/maven/ main/java/org/apache/maven/execution/ main/java/org/apache/maven/lifecycle/ main/java/org/apache/mave
Why an abstract class (abstract class
AbstractMavenLifecycleParticipant) and not an interface ?
Perso, I'd prefer to
lifecycleListeners = container.lookupList( MavenLifecycleParticipant.class );
instead of
lifecycleListeners = container.lookupList(
AbstractMavenLifecycleParticipant.class );
--
Olivier
2009/7/1 bentm...@apache.org:
Author: bentmann
Date: Tue Jun 30 22:36:30 2009
New Revision: 789993
URL: http://svn.apache.org/viewvc?rev=789993view=rev
Log:
[MNG-4224] maven lifecycle participant
Submitted by: Igor Fedorenko
Added:
maven/components/trunk/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java
(with props)
maven/components/trunk/maven-core/src/test/java/org/apache/maven/MavenLifecycleParticipantTest.java
(with props)
maven/components/trunk/maven-core/src/test/projects/lifecycle-listener/
(with props)
maven/components/trunk/maven-core/src/test/projects/lifecycle-listener/lifecycle-listener-dependency-injection/
(with props)
maven/components/trunk/maven-core/src/test/projects/lifecycle-listener/lifecycle-listener-dependency-injection/pom.xml
(with props)
Modified:
maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
maven/components/trunk/maven-core/src/main/java/org/apache/maven/execution/MavenSession.java
maven/components/trunk/maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycleExecutor.java
maven/components/trunk/maven-core/src/main/java/org/apache/maven/plugin/DefaultPluginManager.java
maven/components/trunk/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
maven/components/trunk/maven-core/src/test/java/org/apache/maven/MavenTest.java
Added:
maven/components/trunk/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java
URL:
http://svn.apache.org/viewvc/maven/components/trunk/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java?rev=789993view=auto
==
---
maven/components/trunk/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java
(added)
+++
maven/components/trunk/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java
Tue Jun 30 22:36:30 2009
@@ -0,0 +1,54 @@
+package org.apache.maven;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to you under the Apache
License, Version 2.0 (the
+ * License); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express
+ * or implied. See the License for the specific language governing
permissions and limitations under
+ * the License.
+ */
+
+
+import org.apache.maven.execution.MavenSession;
+
+/**
+ * Allows core extensions to participate in build lifecycle.
+ *
+ * All callback methods (will) follow beforeXXX/afterXXX naming pattern to
+ * indicate at what lifecycle point it is being called.
+ *
+ */
+public abstract class AbstractMavenLifecycleParticipant
+{
+
+ /**
+ * Invoked after all MavenProject instances have been created.
+ *
+ * This callback is intended to allow extensions to manipulate
MavenProjects
+ * before they are sorted and actual build execution starts.
+ */
+ public void afterProjectsRead( MavenSession session ) throws
MavenExecutionException
+ {
+ // do nothing
+ }
+
+ /**
+ * Invoked after MavenSession instance has been created.
+ *
+ * This callback is intended to allow extensions to inject execution
properties,
+ * activate profiles and perform similar tasks that affect MavenProject
+ * instance construction.
+ */
+ public void afterSessionStart( MavenSession session ) throws
MavenExecutionException
+ {
+ // do nothing
+ }
+
+}
Propchange:
maven/components/trunk/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java
--
svn:eol-style = native
Propchange:
maven/components/trunk/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java
--
svn:keywords = Author Date Id Revision
Modified:
maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
URL:
Re: svn commit: r789993 - in /maven/components/trunk/maven-core/src: main/java/org/apache/maven/ main/java/org/apache/maven/execution/ main/java/org/apache/maven/lifecycle/ main/java/org/apache/maven/
On 1-Jul-09, at 2:54 PM, Olivier Lamy wrote:
Why an abstract class (abstract class
AbstractMavenLifecycleParticipant) and not an interface ?
Matter of preference but generally to help with the evolution of the
implementation.
Perso, I'd prefer to
lifecycleListeners =
container.lookupList( MavenLifecycleParticipant.class );
instead of
lifecycleListeners = container.lookupList(
AbstractMavenLifecycleParticipant.class );
Both of these will be changed to use injection but there are some bugs
left in Plexus. In order to use Guice there is no direct access to the
container.
--
Olivier
2009/7/1 bentm...@apache.org:
Author: bentmann
Date: Tue Jun 30 22:36:30 2009
New Revision: 789993
URL: http://svn.apache.org/viewvc?rev=789993view=rev
Log:
[MNG-4224] maven lifecycle participant
Submitted by: Igor Fedorenko
Added:
maven/components/trunk/maven-core/src/main/java/org/apache/maven/
AbstractMavenLifecycleParticipant.java (with props)
maven/components/trunk/maven-core/src/test/java/org/apache/maven/
MavenLifecycleParticipantTest.java (with props)
maven/components/trunk/maven-core/src/test/projects/lifecycle-
listener/ (with props)
maven/components/trunk/maven-core/src/test/projects/lifecycle-
listener/lifecycle-listener-dependency-injection/ (with props)
maven/components/trunk/maven-core/src/test/projects/lifecycle-
listener/lifecycle-listener-dependency-injection/pom.xml (with
props)
Modified:
maven/components/trunk/maven-core/src/main/java/org/apache/maven/
DefaultMaven.java
maven/components/trunk/maven-core/src/main/java/org/apache/maven/
execution/MavenSession.java
maven/components/trunk/maven-core/src/main/java/org/apache/maven/
lifecycle/DefaultLifecycleExecutor.java
maven/components/trunk/maven-core/src/main/java/org/apache/maven/
plugin/DefaultPluginManager.java
maven/components/trunk/maven-core/src/main/java/org/apache/maven/
project/MavenProject.java
maven/components/trunk/maven-core/src/test/java/org/apache/maven/
MavenTest.java
Added: maven/components/trunk/maven-core/src/main/java/org/apache/
maven/AbstractMavenLifecycleParticipant.java
URL:
http://svn.apache.org/viewvc/maven/components/trunk/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java?rev=789993view=auto
=
=
=
=
=
=
=
=
=
=
--- maven/components/trunk/maven-core/src/main/java/org/apache/
maven/AbstractMavenLifecycleParticipant.java (added)
+++ maven/components/trunk/maven-core/src/main/java/org/apache/
maven/AbstractMavenLifecycleParticipant.java Tue Jun 30 22:36:30 2009
@@ -0,0 +1,54 @@
+package org.apache.maven;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or
more contributor license
+ * agreements. See the NOTICE file distributed with this work for
additional information regarding
+ * copyright ownership. The ASF licenses this file to you under
the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance with
the License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
software distributed under the License
+ * is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR
CONDITIONS OF ANY KIND, either express
+ * or implied. See the License for the specific language governing
permissions and limitations under
+ * the License.
+ */
+
+
+import org.apache.maven.execution.MavenSession;
+
+/**
+ * Allows core extensions to participate in build lifecycle.
+ *
+ * All callback methods (will) follow beforeXXX/afterXXX naming
pattern to
+ * indicate at what lifecycle point it is being called.
+ *
+ */
+public abstract class AbstractMavenLifecycleParticipant
+{
+
+/**
+ * Invoked after all MavenProject instances have been created.
+ *
+ * This callback is intended to allow extensions to manipulate
MavenProjects
+ * before they are sorted and actual build execution starts.
+ */
+public void afterProjectsRead( MavenSession session ) throws
MavenExecutionException
+{
+// do nothing
+}
+
+/**
+ * Invoked after MavenSession instance has been created.
+ *
+ * This callback is intended to allow extensions to inject
execution properties,
+ * activate profiles and perform similar tasks that affect
MavenProject
+ * instance construction.
+ */
+public void afterSessionStart( MavenSession session ) throws
MavenExecutionException
+{
+// do nothing
+}
+
+}
Propchange: maven/components/trunk/maven-core/src/main/java/org/
apache/maven/AbstractMavenLifecycleParticipant.java
--
svn:eol-style = native
Propchange: maven/components/trunk/maven-core/src/main/java/org/
Making the Ant Tasks obey mirrorOf external:*
Paul, I made some changes to the Ant Tasks to have the same logic as 2.2 and 3.0 insofar as processing the mirrorOf external:* logic. You want a patch in JIRA or I can check it in and you can review then. Whatever you like. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Prevent posts to issues@
Hi, Sorry for picking this up late. I'm pretty sure that's possible, would you mind filing it in the INFRA JIRA? On 21/05/2009, at 9:43 PM, Benjamin Bentmann wrote: Hi, given that occasionally users post to issues@ I wonder if it would be feasible to block any posts to this list if they don't originate from j...@codehaus.org and provide an error message that suggests to post to users@ instead? Benjamin - 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: Prevent posts to issues@
Kohsuke has a robot on dev.java.net that sends reminders to people who post to issues lists telling them that they should not post to the issues list. I wonder could INFRA provide similar functionality -Stephen 2009/7/2 Brett Porter br...@apache.org Hi, Sorry for picking this up late. I'm pretty sure that's possible, would you mind filing it in the INFRA JIRA? On 21/05/2009, at 9:43 PM, Benjamin Bentmann wrote: Hi, given that occasionally users post to issues@ I wonder if it would be feasible to block any posts to this list if they don't originate from j...@codehaus.org and provide an error message that suggests to post to users@ instead? Benjamin - 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
