Re: snapshot range changes in m3
+1 Thinking about it - I like the idea of a (for lack of a better name) ~/.m2/resolutions.xml that provides control over the resolver. First thoughts that come to mind: - missing or empty file - existing 2.x behaviour, -SNAPSHOTS resolved across the board. - profile based (optional?) Maybe something like: resolutions resolution groupIdcom.smxemail.*/groupId artifactId.*/artifactId snapshots enabledtrue/enabled /snapshots /resolution profiles profile idrelease/id resolutions resolution groupId.*/groupId artifactId.*/artifactId snapshots enabledfalse/enabled /snapshots /resolution /resolutions /profile /profiles /resolutions As much as I hate mavens use of elements only, the above conforms to the current standard - a somewhat mix between a dependency and a repository definition. I like the notion of enabling resolution based on profile, which is already an accepted way of dynamically altering pom resolution. What do you guys think of something like this? If something like this was adopted, would it be doable for 3.0? ( having no clue as to how many layers of maven these things affect ). mark -- Pull me down under... On Thu, Sep 16, 2010 at 1:10 AM, Jason van Zyl ja...@sonatype.com wrote: The approach that I could think of to sufficiently address this issue requires quite some rework of the settings.xml or better a different file in order to not break side-by-side use of Maven 2.x and 3.x. Given that we want to release 3.0 soon, I will probably just rollback the changes for MNG-3092 and restore 2.x behavior, i.e. always include snapshots in ranges, and postpone a more robust solution to 3.1. +1 This is just more consistent with 3.0 being backward compatible, and making the whole scenario of SNAPSHOTs for CI and integration and blocking them from releases will take some more thinking. Only one person has complained but I posit 95% of Maven users aren't going to try Maven 3.x until 3.0 is released.
Re: snapshot range changes in m3
Hervé BOUTEMY wrote: Expected SNAPSHOT dependencies should be in the pom IMHO, since each bits of build info should be there so that mvn compile is sufficient. I agree that we need to aim for a short command line but I'm not convinced the POM can help us here. To me, it looks like a valid use case to build the same project/POM once with and once without snapshots. For example, think about a project where the development policy is to pick up only released versions of dependencies, e.g. in order to avoid destabilizing downstream projects while the dependency snapshots for the next versions are in flux. Still, they might want to have some CI build that integrates the snapshots to allow for early feedback regarding the qualiity of the next release. CI builds from the same sources, this is why I was thinking about a CLI option. But something I didn't think about properly are big products that consist of artifacts from various different groupIds. When such a product build is expected to consume snapshots from all its dependencies, the proposed default value for -sv isn't appropriate and developers would be required to explicitly list the coordinates. Apart from being cumbersome, this makes it harder to synchronize a team of developers to have them get the same build results. I have no solution right now and need to think about this some more. Maybe the settings.xml can help (my previous concern about using this during a release can be easily solved by the rule that non-snapshot projects never ever consume snapshot dependencies for ranges). Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: snapshot range changes in m3
Benjamin Bentmann wrote: I have no solution right now and need to think about this some more. The approach that I could think of to sufficiently address this issue requires quite some rework of the settings.xml or better a different file in order to not break side-by-side use of Maven 2.x and 3.x. Given that we want to release 3.0 soon, I will probably just rollback the changes for MNG-3092 and restore 2.x behavior, i.e. always include snapshots in ranges, and postpone a more robust solution to 3.1. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: snapshot range changes in m3
On Sep 15, 2010, at 8:55 AM, Benjamin Bentmann wrote: Benjamin Bentmann wrote: I have no solution right now and need to think about this some more. The approach that I could think of to sufficiently address this issue requires quite some rework of the settings.xml or better a different file in order to not break side-by-side use of Maven 2.x and 3.x. Given that we want to release 3.0 soon, I will probably just rollback the changes for MNG-3092 and restore 2.x behavior, i.e. always include snapshots in ranges, and postpone a more robust solution to 3.1. +1 This is just more consistent with 3.0 being backward compatible, and making the whole scenario of SNAPSHOTs for CI and integration and blocking them from releases will take some more thinking. Only one person has complained but I posit 95% of Maven users aren't going to try Maven 3.x until 3.0 is released. Benjamin - 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 - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C.
Re: snapshot range changes in m3
Le mercredi 15 septembre 2010, Benjamin Bentmann a écrit : Hervé BOUTEMY wrote: Expected SNAPSHOT dependencies should be in the pom IMHO, since each bits of build info should be there so that mvn compile is sufficient. I agree that we need to aim for a short command line but I'm not convinced the POM can help us here. To me, it looks like a valid use case to build the same project/POM once with and once without snapshots. For example, think about a project where the development policy is to pick up only released versions of dependencies, e.g. in order to avoid destabilizing downstream projects while the dependency snapshots for the next versions are in flux. Still, they might want to have some CI build that integrates the snapshots to allow for early feedback regarding the qualiity of the next release. CI builds from the same sources, this is why I was thinking about a CLI option. yes, there can be multiple builds, then CLI option is necessary (think at a Gump-like CI too, where everything is changed to LATEST) But something I didn't think about properly are big products that consist of artifacts from various different groupIds. When such a product build is expected to consume snapshots from all its dependencies, the proposed default value for -sv isn't appropriate and developers would be required to explicitly list the coordinates. Apart from being cumbersome, this makes it harder to synchronize a team of developers to have them get the same build results. +1: that's my point with having something in the pom, which defines the normal build of the team I have no solution right now and need to think about this some more. Maybe the settings.xml can help (my previous concern about using this during a release can be easily solved by the rule that non-snapshot projects never ever consume snapshot dependencies for ranges). I have no solution either :( Hervé 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: snapshot range changes in m3
Le mercredi 15 septembre 2010, Benjamin Bentmann a écrit : Benjamin Bentmann wrote: I have no solution right now and need to think about this some more. The approach that I could think of to sufficiently address this issue requires quite some rework of the settings.xml or better a different file in order to not break side-by-side use of Maven 2.x and 3.x. Given that we want to release 3.0 soon, I will probably just rollback the changes for MNG-3092 and restore 2.x behavior, i.e. always include snapshots in ranges, and postpone a more robust solution to 3.1. +1 thank you Hervé 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: snapshot range changes in m3
On 14 September 2010 06:22, Hervé BOUTEMY herve.bout...@free.fr wrote: So far I doubt that we can find any magic/heuristic that works for all use cases. Hence I suggest that we go with some explicit configuration. In detail, I propose a CLI option like mvn goals --snapshot-versions gid,-gid:aid,*:aid This is meant to give a comma-separated list of glob-like inclusion/exclusion patterns (exclusions marked by prefixing with '-' or '!' like profiles) to denote the groupId:artifactId tuples of projects/artifacts whose snapshots are acceptable for ranges during the build. These patterns would be applied on the set of available versions before the range filters them, i.e. even a range giving snapshots explicitly like [2.0-SNAPSHOT,) would not select 2.0-SNAPSHOT unless enabled on CLI for the artifact in question. this seems a reasonable approach IMHO clearly, it fixes my main concern: version ranges are back to mathematical notion I don't really understand the use cases where problems happen (even it has already been told), then my opinion on this point is not really a good indicator This new option, -sv in short form, would apply to the entire reactor. If somebody sees a good use case that requires to treat some projects within a reactor differently or to treat project dependency resolution and plugin resolution differently, please speak up. For the common case where one wants to consume snapshots of related projects, there should be a way to avoid the addition of -sv to the CLI. To address this case, I suggest to have Maven derive a default value for the -sv option by considering the groupIds of all snapshot projects in the reactor as inclusions. This is somewhat a combination of Mark's option 2 and my other thought which should make Maven usually do the right thing for builds, both during every day development and during a release (where no snapshot projects are in the reactor and hence the default -sv value would be emtpy and thereby disables any snapshots for ranges). perhaps a special property in the pom.xml too, to avoid CLI-only and improve reproducibility? What would be the use case not covered by previous common case? would the release plugin therefore have to remote the property during a release and then put it back in again also properties are not known until after the model is constructed at which point it's too late I think we need something along the lines of benjamin's proposal, but I'd like to see some concrete examples of how it would work, on e.g. a wiki page -Stephen Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: snapshot range changes in m3
Stephen Connolly wrote: perhaps a special property in the pom.xml too, to avoid CLI-only and improve reproducibility? would the release plugin therefore have to remote the property during a release and then put it back in again also properties are not known until after the model is constructed at which point it's too late I agree with Stephen, having a special property that other tooling like the Release Plugin needs to be aware of sounds like superfluous complexity. And whether it's a POM property or later a dedicated POM element, the process of model building already involves artifact resolution (parents, imports/mixins, extensions) so I really think the snapshot resolution behavior should be set up front and not change somewhere down the road. Also, what exactly is the issue with CLI-only? I was once thinking about an addition to the settings.xml but that doesn't play nicely with the release process where you want Maven to never include snapshots. I think we need something along the lines of benjamin's proposal, but I'd like to see some concrete examples of how it would work, on e.g. a wiki page Apart from diving into implementation details, my proposal is pretty detailed. So if something is unclear, please raise concrete questions. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: snapshot range changes in m3
Hervé BOUTEMY wrote: What would be the use case not covered by previous common case? Well, I assumed it would be the common case that project gid:aid would want to consume snapshots of other projects from the gid domain. But that doesn't have to be the case, just because project A shares the same groupId with project B doesn't necessarily mean project A want to use B's snapshots. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: snapshot range changes in m3
Benjamin Bentmann wrote: For the common case where one wants to consume snapshots of related projects, [...] I suggest to have Maven derive a default value for the -sv option by considering the groupIds of all snapshot projects in the reactor as inclusions. A detail that could be further discussed/reviewed here is the convention/assumption what is actually a related project. If the current project has the groupId X, should the default -sv value only consist of the same groupId or also include sub groups, i.e. should Maven assume --snapshot-versions Xor --snapshot-versions X,X.* Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: snapshot range changes in m3
Both options would be nice, but I think I'm leaning more in against including sub groups in the default set. A different group is after all, a different group ( and probably a different group for a reason ). Mark -- Pull me down under... On Tue, Sep 14, 2010 at 10:18 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: A detail that could be further discussed/reviewed here is the convention/assumption what is actually a related project. If the current project has the groupId X, should the default -sv value only consist of the same groupId or also include sub groups, i.e. should Maven assume --snapshot-versions Xor --snapshot-versions X,X.*
Re: snapshot range changes in m3
Le mardi 14 septembre 2010, Benjamin Bentmann a écrit : Stephen Connolly wrote: perhaps a special property in the pom.xml too, to avoid CLI-only and improve reproducibility? would the release plugin therefore have to remote the property during a release and then put it back in again also properties are not known until after the model is constructed at which point it's too late I agree with Stephen, having a special property that other tooling like the Release Plugin needs to be aware of sounds like superfluous complexity. And whether it's a POM property or later a dedicated POM element, the process of model building already involves artifact resolution (parents, imports/mixins, extensions) so I really think the snapshot resolution behavior should be set up front and not change somewhere down the road. Also, what exactly is the issue with CLI-only? I was once thinking about an addition to the settings.xml but that doesn't play nicely with the release process where you want Maven to never include snapshots. the idea is that the expected compile command during the development/SNAPSHOT phase would not be mvn compile but mvn -sv gid,... compile, and if there is an API change in SNAPSHOT dependencies, mvn compile would even fail. Expected SNAPSHOT dependencies should be in the pom IMHO, since each bits of build info should be there so that mvn compile is sufficient. Then release plugin would not be in charge of *removing* the property: the release plugin should only fail if the pom says it needs SNAPSHOT dependencies, and the developper has to change it to remove these SNAPSHOTs. Note that I don't know precisely how release plugin detects SNAPSHOT dependencies: does it do its own pom.xml analysis or use core API to resolve depencies then checks that no SNAPSHOT has been resolved? Of course, the idea of a property is just to avoid changing the pom format until we have a viable solution: adding an element is the real need, property only a workaround. Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: snapshot range changes in m3
Brian Fox wrote: Two options come to mind: 1) Explicit GAV patterns for -SNAPSHOT resolution get defined somewhere 2) If a GAV is a particpant in a reactor build, it's -SNAPSHOT should be considered kosher for resolution Option 1 would probably require some form of POM change as I don't think the resolution part of a configurable plugin, so most likely can't be done. Option 2 should be fine, as when releasing an individual artifact, nothing external would be in the reactor, unless it was part of the build chain, so no extraneous -SNAPSHOTs would be considered. This should give a fairly good compromise between fixing ranges for release and not breaking existing builds. Seems logical to me [...] Certainly I could see this being a problem that's worth trying to address prior to M3.0 if it's not risky. Agreed, that issue is a trouble-maker for builds and I wanted to look into that next now that the other regressions I know about are fixed. But I think option 2 isn't workable either. For one, I dislike the idea that a reactor build and an isolated module build behave noticeable different. Consider this command session from an aggregator project's basedir: $ mvn install $ cd sub-module $ mvn install As a user, I would have a very hard time to understand that the initial mvn install picks snapshots while the later mvn install on a single module doesn't, despite just having installed snapshots of all the other modules. And I think this scenario reflects a common build pattern, where a developer starts his day with updating the entire code base from SCM, does a full build of the updated code base and then continues the rest of his work on only a few modules. But more importantly, option 2 would not guarantee that a release build doesn't use snapshots (cf. MRELEASE-216). While during a release the reactor itself doesn't produce snapshots, a version range could still select a snapshot from the repos. Another option that came to my mind was using the current project's version as the controlling factor. If the project itself is a SNAPSHOT, allow it to select snapshots for its direct dependencies, otherwise not. But this is also troublesome, whether one wants to consume snapshots (in particular of third-parties) should be independent from the current project. So far I doubt that we can find any magic/heuristic that works for all use cases. Hence I suggest that we go with some explicit configuration. In detail, I propose a CLI option like mvn goals --snapshot-versions gid,-gid:aid,*:aid This is meant to give a comma-separated list of glob-like inclusion/exclusion patterns (exclusions marked by prefixing with '-' or '!' like profiles) to denote the groupId:artifactId tuples of projects/artifacts whose snapshots are acceptable for ranges during the build. These patterns would be applied on the set of available versions before the range filters them, i.e. even a range giving snapshots explicitly like [2.0-SNAPSHOT,) would not select 2.0-SNAPSHOT unless enabled on CLI for the artifact in question. This new option, -sv in short form, would apply to the entire reactor. If somebody sees a good use case that requires to treat some projects within a reactor differently or to treat project dependency resolution and plugin resolution differently, please speak up. For the common case where one wants to consume snapshots of related projects, there should be a way to avoid the addition of -sv to the CLI. To address this case, I suggest to have Maven derive a default value for the -sv option by considering the groupIds of all snapshot projects in the reactor as inclusions. This is somewhat a combination of Mark's option 2 and my other thought which should make Maven usually do the right thing for builds, both during every day development and during a release (where no snapshot projects are in the reactor and hence the default -sv value would be emtpy and thereby disables any snapshots for ranges). WDYT? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: snapshot range changes in m3
Having read this a few times I think it sounds solid. I like the default inclusion of snapshot groups in the build as a default, this will help existing users move along without really seeing any changes in their behavior. Would it be good to also log a warning note to the console to report the snapshots being pulled in? +1 Mark -- Pull me down under... On Tue, Sep 14, 2010 at 3:13 AM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: For the common case where one wants to consume snapshots of related projects, there should be a way to avoid the addition of -sv to the CLI. To address this case, I suggest to have Maven derive a default value for the -sv option by considering the groupIds of all snapshot projects in the reactor as inclusions. This is somewhat a combination of Mark's option 2 and my other thought which should make Maven usually do the right thing for builds, both during every day development and during a release (where no snapshot projects are in the reactor and hence the default -sv value would be emtpy and thereby disables any snapshots for ranges).
Re: snapshot range changes in m3
So far I doubt that we can find any magic/heuristic that works for all use cases. Hence I suggest that we go with some explicit configuration. In detail, I propose a CLI option like mvn goals --snapshot-versions gid,-gid:aid,*:aid This is meant to give a comma-separated list of glob-like inclusion/exclusion patterns (exclusions marked by prefixing with '-' or '!' like profiles) to denote the groupId:artifactId tuples of projects/artifacts whose snapshots are acceptable for ranges during the build. These patterns would be applied on the set of available versions before the range filters them, i.e. even a range giving snapshots explicitly like [2.0-SNAPSHOT,) would not select 2.0-SNAPSHOT unless enabled on CLI for the artifact in question. this seems a reasonable approach IMHO clearly, it fixes my main concern: version ranges are back to mathematical notion I don't really understand the use cases where problems happen (even it has already been told), then my opinion on this point is not really a good indicator This new option, -sv in short form, would apply to the entire reactor. If somebody sees a good use case that requires to treat some projects within a reactor differently or to treat project dependency resolution and plugin resolution differently, please speak up. For the common case where one wants to consume snapshots of related projects, there should be a way to avoid the addition of -sv to the CLI. To address this case, I suggest to have Maven derive a default value for the -sv option by considering the groupIds of all snapshot projects in the reactor as inclusions. This is somewhat a combination of Mark's option 2 and my other thought which should make Maven usually do the right thing for builds, both during every day development and during a release (where no snapshot projects are in the reactor and hence the default -sv value would be emtpy and thereby disables any snapshots for ranges). perhaps a special property in the pom.xml too, to avoid CLI-only and improve reproducibility? What would be the use case not covered by previous common case? Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: snapshot range changes in m3
I created a Wiki page to be able to share pointers: http://docs.codehaus.org/display/MAVENUSER/SNAPSHOT+Resolution regards, Hervé Le vendredi 03 septembre 2010, Mark Derricutt a écrit : Any pointers to where in the code base I should start looking/hacking if I wanted to try and write such a patch? As I'm the main one arguing for this improvement, I'm willing to at least try and solve it :) Seems logical to me, not sure how much work that is to fix, but patches would be a good way to ensure this gets in. Certainly I could see this being a problem that's worth trying to address prior to M3.0 if it's not risky. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: snapshot range changes in m3
I'd had a similar thought initially, but I've not really looked at the internals of maven yet to know if there is such a distinct thing, or a pluggable resolver ( I did see that the resolution was on the VersionRange class so I suspect maybe there isn't ). Mark -- Pull me down under... On Fri, Sep 3, 2010 at 5:40 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Here are my thought for now: the fix should not have been done in VersionRange but in a version conflict resolution phase, since a range is a mathematical notion we can't alter.
snapshot range changes in m3
Forking this discussion: On Thu, Sep 2, 2010 at 9:12 PM, Mark Derricutt m...@talios.com wrote: Personally I'd still like to see some resolution to the problems introduced by the version range resolution change ( no more -SNAPSHOT resolution except for on the bounds ). On one hand I applaud the change from a release standpoint, but it currently causes issues for our integration build processes. Two options come to mind: 1) Explicit GAV patterns for -SNAPSHOT resolution get defined somewhere 2) If a GAV is a particpant in a reactor build, it's -SNAPSHOT should be considered kosher for resolution Option 1 would probably require some form of POM change as I don't think the resolution part of a configurable plugin, so most likely can't be done. Not possible for 3.0 Option 2 should be fine, as when releasing an individual artifact, nothing external would be in the reactor, unless it was part of the build chain, so no extraneous -SNAPSHOTs would be considered. This should give a fairly good compromise between fixing ranges for release and not breaking existing builds. Seems logical to me, not sure how much work that is to fix, but patches would be a good way to ensure this gets in. Certainly I could see this being a problem that's worth trying to address prior to M3.0 if it's not risky. Each time I've brought the subject up I don't seem to see any traction or replies/discussion come along, is there room to address this somehow? -- Pull me down under... On Fri, Sep 3, 2010 at 11:34 AM, Brian Fox bri...@infinity.nu wrote: Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty safely call it feature complete. I'd like to propose a few goals to get some things done. We have ApacheCon coming up the first week of November, and it would be great to set that as a target to get Maven 3.0 out the door. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: snapshot range changes in m3
Any pointers to where in the code base I should start looking/hacking if I wanted to try and write such a patch? As I'm the main one arguing for this improvement, I'm willing to at least try and solve it :) -- Pull me down under... On Fri, Sep 3, 2010 at 1:27 PM, Brian Fox bri...@infinity.nu wrote: Seems logical to me, not sure how much work that is to fix, but patches would be a good way to ensure this gets in. Certainly I could see this being a problem that's worth trying to address prior to M3.0 if it's not risky.
Re: snapshot range changes in m3
I'm concerned by this fix too. Here are my thought for now: the fix should not have been done in VersionRange but in a version conflict resolution phase, since a range is a mathematical notion we can't alter. but I didn't have time yet to transform these thoughts in code... Regards, Hervé Le vendredi 03 septembre 2010, Brian Fox a écrit : Forking this discussion: On Thu, Sep 2, 2010 at 9:12 PM, Mark Derricutt m...@talios.com wrote: Personally I'd still like to see some resolution to the problems introduced by the version range resolution change ( no more -SNAPSHOT resolution except for on the bounds ). On one hand I applaud the change from a release standpoint, but it currently causes issues for our integration build processes. Two options come to mind: 1) Explicit GAV patterns for -SNAPSHOT resolution get defined somewhere 2) If a GAV is a particpant in a reactor build, it's -SNAPSHOT should be considered kosher for resolution Option 1 would probably require some form of POM change as I don't think the resolution part of a configurable plugin, so most likely can't be done. Not possible for 3.0 Option 2 should be fine, as when releasing an individual artifact, nothing external would be in the reactor, unless it was part of the build chain, so no extraneous -SNAPSHOTs would be considered. This should give a fairly good compromise between fixing ranges for release and not breaking existing builds. Seems logical to me, not sure how much work that is to fix, but patches would be a good way to ensure this gets in. Certainly I could see this being a problem that's worth trying to address prior to M3.0 if it's not risky. Each time I've brought the subject up I don't seem to see any traction or replies/discussion come along, is there room to address this somehow? -- Pull me down under... On Fri, Sep 3, 2010 at 11:34 AM, Brian Fox bri...@infinity.nu wrote: Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty safely call it feature complete. I'd like to propose a few goals to get some things done. We have ApacheCon coming up the first week of November, and it would be great to set that as a target to get Maven 3.0 out the door. - 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
