Re: Maven 2.2.2 soon?
On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote: I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins. So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough. I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be. And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner. Here is an example of what I am talking about. The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided. project groupId=org.apache.commons artifactId=commons-logging version=1.2 provides provide id=commons-logging-api version=1.1/ provide id=commons-logging-api version=1.2/ /provides /project project groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0 provides provide id=commons-logging-api version=1.1/ /provides /project project groupId=com.mycorp.test artifactId=myapp version=1.0 dependencyManagement dependencies dependency groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0/ /dependencies /dependencyManagement dependencies requires id=org.springsource.spring-core version compare=ge3.1/version /requires dependencies /project project groupId=org.springsource artifactId=spring-core version=3.1 dependencyManagement dependencies dependency groupId=org.apache.commons artifactId=commons-logging version=1.2/ /dependencies /dependencyManagement depencencies requires id=commons-logging-api version=1.1/ /dependencies /project
Re: svn commit: r894490 - /maven/plugins/trunk/maven-compiler-plugin/pom.xml
Let's go ! BTW If you have time between changing nappy :-)) -- Olivier 2009/12/30 Stephen Connolly stephen.alan.conno...@gmail.com: so am I good to go tomorrow morning? Sent from my [rhymes with tryPod] ;-) On 29 Dec 2009, at 22:02, ol...@apache.org wrote: Author: olamy Date: Tue Dec 29 22:02:56 2009 New Revision: 894490 URL: http://svn.apache.org/viewvc?rev=894490view=rev Log: use plexus-compiler released version. Modified: maven/plugins/trunk/maven-compiler-plugin/pom.xml Modified: maven/plugins/trunk/maven-compiler-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-compiler-plugin/pom.xml?rev=894490r1=894489r2=894490view=diff === === === = --- maven/plugins/trunk/maven-compiler-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-compiler-plugin/pom.xml Tue Dec 29 22:02:56 2009 @@ -78,7 +78,7 @@ dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-compiler-api/artifactId - version1.6-SNAPSHOT/version + version1.6/version exclusions exclusion groupIdorg.codehaus.plexus/groupId @@ -94,7 +94,7 @@ dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-compiler-manager/artifactId - version1.6-SNAPSHOT/version + version1.6/version exclusions exclusion groupIdorg.codehaus.plexus/groupId @@ -105,7 +105,7 @@ dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-compiler-javac/artifactId - version1.6-SNAPSHOT/version + version1.6/version scoperuntime/scope exclusions exclusion @@ -123,19 +123,6 @@ /dependency /dependencies - repositories - repository - idcodehaus.snapshots/id - urlhttp://snapshots.repository.codehaus.org//url - snapshots - enabledtrue/enabled - /snapshots - releases - enabledfalse/enabled - /releases - /repository - /repositories - profiles profile idrun-its/id - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Apache Parent POM 7
Hi, The vote has passed with the following result: +1 (binding): Benjamin Bentmann, Dennis Lundberg, Olivier Lamy, Arnaud Héritier, Hervé Boutemy, Vincent Siveton, Brett Porter I will promote the artifacts to the central repository and continue with the release. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Compiler plugin version 2.1
Hi, We solved 11 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130version=12304styleName=Html There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11130status=1 Staging repo: https://repository.apache.org/content/repositories/maven-011/ Staging site: http://maven.apache.org/plugins/maven-compiler-plugin-2.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 This plugin has additionally been tested on the sonatype grid (https://grid.sonatype.org/ci/) against the following projects: * archetype * m3 * scm * surefire * release * wagon * core-its * modello * shared -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Parent POM 7 Released
The Maven team is pleased to announce the release of the Apache Parent POM, version 7. This POM provides a base configuration for ASF projects build with Apache Maven [0]. Besides some updated plugin versions, the most interesting change in this version of the POM is the inclusion of a configuration for the Maven Assembly Plugin to produce ASF-compliant source distributions. Please see [1] for a detailed diff to the previous version. In more detail, the Assembly Plugin configuration for the source distribution is part of the profile apache-release that was already introduced in version 6 of the parent POM. This configuration creates a ZIP archive containing the project's sources at the root module of the release process. Projects with different needs regarding the source distribution and/or release process have the following options: a) Create a custom assembly descriptor (see [2]) for the source distribution and set the POM property sourceReleaseAssemblyDescriptor to its name. b) Disable the predefined execution source-release-assembly of the Assembly Plugin via the following POM snippet: plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-5/version executions execution idsource-release-assembly/id configuration skipAssemblytrue/skipAssembly /configuration /execution /executions /plugin c) Configure the Maven Release Plugin to use another release profile than the predefined apache-release via something like this: plugin artifactIdmaven-release-plugin/artifactId version2.0-beta-9/version configuration arguments-Pcustom-release/arguments /configuration /plugin Note: Version 2.2-beta-5 of the Maven Assembly Plugin is required for proper creation of the source distribution. Please be sure to check the plugin version used is not locked down to an older version in some of your downstream POMs. Use the following snippet to inherit from this POM for your Maven managed projects: parent groupIdorg.apache/groupId artifactIdapache/artifactId version7/version /parent Enjoy, -The Maven team [0] http://maven.apache.org/ [1] http://svn.apache.org/viewvc/maven/pom/trunk/asf/pom.xml?r1=766951r2=893966 [2] http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 2.2.2 soon?
On 2009-12-30, at 1:48 AM, Arnaud HERITIER wrote: On Wed, Dec 30, 2009 at 2:45 AM, Jason van Zyl ja...@sonatype.com wrote: On 2009-12-29, at 8:05 PM, Arnaud HERITIER wrote: What I recall discussing with Brian at ApacheCon was having a new project descriptor but making sure that when projects are installed or deployed a pom compatible with the current format would also be deployed along with the new descriptor. If the new project descriptor allows extension then this could continue to work as things change. Yah, I think we've been beating this around for a while... in my mind, it's still a unified repository metadata format that the POM translates to (and a parallel 4.0.0 POM / maven-metadata for old clients). It seems like that and the POM and the deprecations can be the single focus for 3.1... we just need to ship Snow Maven at this point so we can move on to new things. Do we have in 3.0 a mechanism to have a constraint when we develop a plugin to say that it requires a minimal version of POM. I would argue this should never happen in the future. A plugin should define what it needs in its own configuration. I'm also going to push for getting plugin specific POM elements back into the plugins that operate on that data. Like pushing the resources elements into the resources plugin, the distribution management information back into the deploy plugin, source roots to the compiler plugin and anything akin to it. It's the only way to continue scaling. There are changes that need to be made to the POM but I really don't want to see proliferation of POM elements to service specific plugins. I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins. ok for me to push what we can in plugins configurations but won't we have quickly some plugins incompatibilities because they'll share some info like resources, sources and many others (encoding, compiler version) and if the plugin which stores this info changes the name of the config or something like that, all others will be broken ? I wouldn't like we have again the maven 1 experience where plugins used others and finally we didn't control them ! Arnaud, seriously don't worry about it right now. Let's get 3.0 out the door and there is a ton to do just in that. Everything is the same right now, 3.0 should be a drop in replacement. Let's not get ahead of ourselves. Another thing if we move more data in plugins is the verbosity of our config. Even if we'll have alternative format, instead of overriding/extending build/resource we'll have to do it in build/plugins/plugin/config/resources . (many lines for a little change). To end another disadvantage to have more things in plugins config is that we won't validate them (with a schema and at runtime) and we'll ignore wrong settings which is always a big issues for our users because they don't quickly see if they made a misprint in the config. Let's imagine we add a new data in the pom in 4.1.0 and a plugin needs to use them, thus maven shouldn't automatically check when it load a plugin that it is compatible with the POM version. Sure, we can augment whatever is necessary in preparation for 3.1. Another question about 3.0, did we reintroduce // dowloads ? I think it wasn't here in the last alpha. One form of it is in the Jetty Wagon we have at Sonatype. There is a new interface called the RepositorySystem which encapsulates everything with far fewer interfaces then the legacy system. We also have another set of interfaces which is a complete internal replacement. Benjamin has this on a branch. So if someone wants to try and implement or backport Don's work then that's cool too. If we want to get a 3.0 sometime around the beginning of February then I'm not sure that will make it into 3.0. Might be soon after that. I'm still more in favour IT quality, getting the JIRA issues cleaned up and getting out the 3.0. If people want this released soonish and want specific features then speak now and commit your time. Arnaud Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - 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 unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 2.2.2 soon?
Seriously, please focus on 3.0. On 2009-12-30, at 1:55 AM, Paul Benedict wrote: Jason, Are you suggesting that the elements of the POM body might belong to each respective plugin? An academic example, but to get the point across: project plugin:compiler execution iddefault/id ... configuration target1.4/target /configuration /execution execution idanother/id ... configuration target1.5/target /configuration /execution /plugin:compiler plugin:release.../plugin:release /project Paul - 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 unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 2.2.2 soon?
Same thing, please focus on 3.0. On 2009-12-30, at 3:22 AM, Ralph Goers wrote: On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote: I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins. So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough. I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be. And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner. Here is an example of what I am talking about. The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided. project groupId=org.apache.commons artifactId=commons-logging version=1.2 provides provide id=commons-logging-api version=1.1/ provide id=commons-logging-api version=1.2/ /provides /project project groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0 provides provide id=commons-logging-api version=1.1/ /provides /project project groupId=com.mycorp.test artifactId=myapp version=1.0 dependencyManagement dependencies dependency groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0/ /dependencies /dependencyManagement dependencies requires id=org.springsource.spring-core version compare=ge3.1/version /requires dependencies /project project groupId=org.springsource artifactId=spring-core version=3.1 dependencyManagement dependencies dependency groupId=org.apache.commons artifactId=commons-logging version=1.2/ /dependencies /dependencyManagement depencencies requires id=commons-logging-api version=1.1/ /dependencies /project Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.? and settings and more
On 2009-12-30, at 3:57 AM, Arnaud HERITIER wrote: Hi, I think there is no change in maven 3.0 about settings.xml ? There are no changes in settings.xml. There will be no changes in settings.xml for 3.0 at this point. Actually there are several problems (from my point of view) : * Mirrors don't support something to catch all releases repo or all snasphots repo. ** It creates a problem because you have to use a unique group in repo managers and then you download SNAPSHOTs versions for CLI plugins. ** Using repoIDs for mirror is unusable because repoIDs aren't unique * Profiles are confusing and can be source of problems if they are badly used. Moreover many things have to be put in profiles (repositories for example) whereas it could be outside. * There is no inheritance/mixins mechanisms to share settings accross an organization / a company / a project thus it is difficult to deploy/keep up to date them There's already a proposal for much of this. I know Brian wanted to talk about it so I'll leave that to him. Regardless this is unlikely to change between now and 3.0. Not really related to settings but to the infrastructure and how maven works we talked several times about having several local repositories. The most interesting feature was to have one dedicated for each build and binaries was moved to another when all the project was build. It could allow to have a form of transaction in the build to not install a part of a project and having inconsistencies. (The problem also exists for deployment The infrastructure for having multiple local repositories is already implemented in the core. This was to simplify IDE integration primarily but would allow multiple local repositories if you wanted on only for snapshots versus releases. - how could we deploy all binaries only when the project is entirely built). This will also not be terribly hard to fix but is a major behavioural change and will require quite a bit of testing. I'm pushing all those questions because you are reviewing our backlog and I don't know if some of these remarks are already filled in Jira. We're not going to anything until it's cleaned up. It's probably pretty near impossible for anyone with only 20 minutes to find anything. Our website, JIRA and Confluence are all not very well organized. So as part of the 3.0 the code, testing, and visibility to the outside world is primarily what I'm going to focus. I think the only sane thing to do is try to move people forward to a well tested replacement for the 2.x line which is a dead end. Cheers, Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.? and settings and more
Arnaud, If you really want to help to let people see what's going to be planned then help cleanup this Confluence page: http://docs.codehaus.org/display/MAVEN/Home and http://docs.codehaus.org/display/MAVEN/All+Proposals There are bits and pieces of all that you've talked about below and if we culled out the dead stuff and things that have been done then it would be easier for people to see what can be done. On 2009-12-30, at 3:57 AM, Arnaud HERITIER wrote: Hi, I think there is no change in maven 3.0 about settings.xml ? Actually there are several problems (from my point of view) : * Mirrors don't support something to catch all releases repo or all snasphots repo. ** It creates a problem because you have to use a unique group in repo managers and then you download SNAPSHOTs versions for CLI plugins. ** Using repoIDs for mirror is unusable because repoIDs aren't unique * Profiles are confusing and can be source of problems if they are badly used. Moreover many things have to be put in profiles (repositories for example) whereas it could be outside. * There is no inheritance/mixins mechanisms to share settings accross an organization / a company / a project thus it is difficult to deploy/keep up to date them Not really related to settings but to the infrastructure and how maven works we talked several times about having several local repositories. The most interesting feature was to have one dedicated for each build and binaries was moved to another when all the project was build. It could allow to have a form of transaction in the build to not install a part of a project and having inconsistencies. (The problem also exists for deployment - how could we deploy all binaries only when the project is entirely built). I'm pushing all those questions because you are reviewing our backlog and I don't know if some of these remarks are already filled in Jira. Cheers, Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Guice OSGi
For folks that want to do some forward looking research and reading on Guice and OSGi here are a few resources. Of course, you can probably find all the standard Guice resources yourself. But ultimately we are going to be interested in the most agnostic form of dependency injection so I'd like to stick with JSR 330 as much as possible. If we need to create a new plugin API then we might make some additions but JSR 330 at the core. We, Sonatype, have attempted to not require any alterations in the existing code. In a nutshell an entirely transparent drop-in replacement for Plexus. Guice does not do classpath scanning, or have lifecycles so we've had to add that support in order to make things work. Nexus uses a lot of the same facilities Maven does so we attempted to make this work for Nexus before attempting this with Maven. The code that we've created to shim Plexus idiom and behaviour into Guice is here: http://svn.sonatype.org/spice/trunk/spice-inject/ It's just one set of binaries versus another to use Guice over Plexus. It simply can't be any other way because all the old plugins and components that have been created need to be supported. So it's not a simple matter of just switching IoC containers. This was not a small job and it has to be a perfect mimic or lots of things will break. It's all there in the code and Stuart is going to try and document this in the short term so people can read about it. We'll figure out in the next week how to make this easy to try for people like Kristian who want to take a look. The next phase is using OSGi for that we plan to use Stuart's Peaberry project which you can find here: http://code.google.com/p/peaberry/ I don't think that OSGi is ideal for typical application development but for plugin-based systems we've just run into the brick wall too many times with Maven 3.0 and Nexus that we need the isolation that OSGi provides and there's no point in rewriting this stuff. But we still are trying to figure out a way not to expose everyone to OSGi. So that users again will not have to do anything differently in the way they extend Maven. Where our problem is going to be is having correct bundle information at runtime. So for JARs that were produced before this work we have a bit of a problem to sort out. Stuart is happy to answer any questions as this is primarily his effort thus far. We're waiting for Kristian to get involved. This stuff is very hot :-) Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven JIRA Bugs
I'm working off this query if anyone wants to lend a hand: http://jira.codehaus.org/secure/IssueNavigator.jspa?pid=10500status=1status=3status=4fixfor=13143fixfor=14504fixfor=16088fixfor=16089fixfor=14118fixfor=16090fixfor=16087fixfor=15103fixfor=16094fixfor=16093fixfor=15565fixfor=15472fixfor=15554fixfor=13145fixfor=13142fixfor=13141fixfor=15996fixfor=14593type=1reset=trueshow=View+%26gt%3B%26gt%3B Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 2.2.2 soon?
I don't know why you are trying to shut off this discussion. Of course we realize 3.0 is what it is. I'm not looking for 3.0 to sit in limbo longer. At the same time, I have wanted the feature below for years. It wasn't doable with the current code base. If 3.0 changes that then great, but if it isn't any more doable with 3.0 then I guess I'm not sure what was gained. Ralph On Dec 30, 2009, at 6:47 AM, Jason van Zyl wrote: Same thing, please focus on 3.0. On 2009-12-30, at 3:22 AM, Ralph Goers wrote: On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote: I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins. So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough. I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be. And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner. Here is an example of what I am talking about. The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided. project groupId=org.apache.commons artifactId=commons-logging version=1.2 provides provide id=commons-logging-api version=1.1/ provide id=commons-logging-api version=1.2/ /provides /project project groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0 provides provide id=commons-logging-api version=1.1/ /provides /project project groupId=com.mycorp.test artifactId=myapp version=1.0 dependencyManagement dependencies dependency groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0/ /dependencies /dependencyManagement dependencies requires id=org.springsource.spring-core version compare=ge3.1/version /requires dependencies /project project groupId=org.springsource artifactId=spring-core version=3.1 dependencyManagement dependencies dependency groupId=org.apache.commons artifactId=commons-logging version=1.2/ /dependencies /dependencyManagement depencencies requires id=commons-logging-api version=1.1/ /dependencies /project Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - 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.2 soon?
Seems like you are looking for an osgi sort of function? -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Wednesday, December 30, 2009 9:03 AM To: Maven Developers List Subject: Re: Maven 2.2.2 soon? I don't know why you are trying to shut off this discussion. Of course we realize 3.0 is what it is. I'm not looking for 3.0 to sit in limbo longer. At the same time, I have wanted the feature below for years. It wasn't doable with the current code base. If 3.0 changes that then great, but if it isn't any more doable with 3.0 then I guess I'm not sure what was gained. Ralph On Dec 30, 2009, at 6:47 AM, Jason van Zyl wrote: Same thing, please focus on 3.0. On 2009-12-30, at 3:22 AM, Ralph Goers wrote: On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote: I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins. So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough. I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be. And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner. Here is an example of what I am talking about. The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided. project groupId=org.apache.commons artifactId=commons-logging version=1.2 provides provide id=commons-logging-api version=1.1/ provide id=commons-logging-api version=1.2/ /provides /project project groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0 provides provide id=commons-logging-api version=1.1/ /provides /project project groupId=com.mycorp.test artifactId=myapp version=1.0 dependencyManagement dependencies dependency groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0/ /dependencies /dependencyManagement dependencies requires id=org.springsource.spring-core version compare=ge3.1/version /requires dependencies /project project groupId=org.springsource artifactId=spring-core version=3.1 dependencyManagement dependencies dependency groupId=org.apache.commons artifactId=commons-logging version=1.2/ /dependencies /dependencyManagement depencencies requires id=commons-logging-api version=1.1/ /dependencies /project Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - 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.2 soon?
On 2009-12-30, at 12:03 PM, Ralph Goers wrote: I don't know why you are trying to shut off this discussion. I am busy trying to do work that's necessary for 3.0. Of course we realize 3.0 is what it is. No, I don't think you do. If you did you would be helping more with 3.0 instead of trying to discuss beyond it. I'm just going to bite my tongue as I don't think what I would say to you would be very constructive. You want a model of how things should work, look at what Dan and Kristian did with the parallelization. I'm not looking for 3.0 to sit in limbo longer. At the same time, I have wanted the feature below for years. It wasn't doable with the current code base. If 3.0 changes that then great, but if it isn't any more doable with 3.0 then I guess I'm not sure what was gained. Then you can figure that out with the rest of the users. I don't know what to tell you. You make me just want to give up on the Maven committers and the Maven PMC in general. You don't think the ITs that have been added, the plugin tests, the performance framework, fixing embedding are not critical for any sort of meaningful future of the project? What has been gained? Are you kidding? Try and look beyond what you want to do. Ralph On Dec 30, 2009, at 6:47 AM, Jason van Zyl wrote: Same thing, please focus on 3.0. On 2009-12-30, at 3:22 AM, Ralph Goers wrote: On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote: I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins. So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough. I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be. And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner. Here is an example of what I am talking about. The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided. project groupId=org.apache.commons artifactId=commons-logging version=1.2 provides provide id=commons-logging-api version=1.1/ provide id=commons-logging-api version=1.2/ /provides /project project groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0 provides provide id=commons-logging-api version=1.1/ /provides /project project groupId=com.mycorp.test artifactId=myapp version=1.0 dependencyManagement dependencies dependency groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0/ /dependencies /dependencyManagement dependencies requires id=org.springsource.spring-core version compare=ge3.1/version /requires dependencies /project project groupId=org.springsource artifactId=spring-core version=3.1 dependencyManagement dependencies dependency groupId=org.apache.commons artifactId=commons-logging version=1.2/ /dependencies /dependencyManagement depencencies requires id=commons-logging-api version=1.1/ /dependencies /project Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - 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
Jetty Wagon
Olivier/Arnaud, You guys seemed to be interested in the Jetty Wagon. The Jetty Client deals with all the parallelization, and we've tried to patch everything in one Wagon to make a decent overall implementation. Jesse has been involved from the start so he can answer any questions as well. Should be a drop in replacement for any Wagon but there is still some testing to be done. Benjamin did the last pass of testing so he can probably update you. John has also worked on it. http://github.com/sonatype/wagon-jetty Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 2.2.2 soon?
On 2009-12-30, at 1:03 PM, Jason van Zyl wrote: On 2009-12-30, at 12:03 PM, Ralph Goers wrote: I don't know why you are trying to shut off this discussion. I am busy trying to do work that's necessary for 3.0. Of course we realize 3.0 is what it is. No, I don't think you do. If you did you would be helping more with 3.0 instead of trying to discuss beyond it. I'm just going to bite my tongue as I don't think what I would say to you would be very constructive. You want a model of how things should work, look at what Dan and Kristian did with the parallelization. Here I also should have added that what Olivier is doing with the site plugin is extremely helpful. He just stepped in and started working on it. We didn't need to have a massive email exchange to get that going either. Ask some questions, talk to someone on IRC (oh no!, not IRC!) and start working. It's that simple. I'm not looking for 3.0 to sit in limbo longer. At the same time, I have wanted the feature below for years. It wasn't doable with the current code base. If 3.0 changes that then great, but if it isn't any more doable with 3.0 then I guess I'm not sure what was gained. Then you can figure that out with the rest of the users. I don't know what to tell you. You make me just want to give up on the Maven committers and the Maven PMC in general. You don't think the ITs that have been added, the plugin tests, the performance framework, fixing embedding are not critical for any sort of meaningful future of the project? What has been gained? Are you kidding? Try and look beyond what you want to do. Ralph On Dec 30, 2009, at 6:47 AM, Jason van Zyl wrote: Same thing, please focus on 3.0. On 2009-12-30, at 3:22 AM, Ralph Goers wrote: On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote: I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins. So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough. I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be. And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner. Here is an example of what I am talking about. The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided. project groupId=org.apache.commons artifactId=commons-logging version=1.2 provides provide id=commons-logging-api version=1.1/ provide id=commons-logging-api version=1.2/ /provides /project project groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0 provides provide id=commons-logging-api version=1.1/ /provides /project project groupId=com.mycorp.test artifactId=myapp version=1.0 dependencyManagement dependencies dependency groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0/ /dependencies /dependencyManagement dependencies requires id=org.springsource.spring-core version compare=ge3.1/version /requires dependencies /project project groupId=org.springsource artifactId=spring-core version=3.1 dependencyManagement dependencies dependency groupId=org.apache.commons artifactId=commons-logging version=1.2/ /dependencies /dependencyManagement depencencies requires id=commons-logging-api version=1.1/ /dependencies /project Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl
Re: Maven 3.? and settings and more
On 31/12/2009, at 2:11 AM, Jason van Zyl wrote: Arnaud, If you really want to help to let people see what's going to be planned then help cleanup this Confluence page: http://docs.codehaus.org/display/MAVEN/Home and http://docs.codehaus.org/display/MAVEN/All+Proposals There are bits and pieces of all that you've talked about below and if we culled out the dead stuff and things that have been done then it would be easier for people to see what can be done. I thought I'd made those readonly, but remember now that I don't have Codehaus confluence admin privs. I've added a notice on the front page. This was already migrated to: http://cwiki.apache.org/confluence/display/MAVENOLD With the intent of migrating anything meaningful into a clean slate at: http://cwiki.apache.org/confluence/display/MAVEN - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Julia Antonova/Tumlare is out of office.
I will be out of the office starting 31.12.2009 and will not return until 11.01.2010. I have no acces to my mailbox, I will reply to your message upon return. For urgent issues please contact my colleagues: Elena Tonoyan / Administration - elen...@tumlare.com Alexandra Sukhova / Administration - secretary...@tumlare.com
Re: Maven 3.? and settings and more
On 2009-12-30, at 6:34 PM, Brett Porter wrote: On 31/12/2009, at 2:11 AM, Jason van Zyl wrote: Arnaud, If you really want to help to let people see what's going to be planned then help cleanup this Confluence page: http://docs.codehaus.org/display/MAVEN/Home and http://docs.codehaus.org/display/MAVEN/All+Proposals There are bits and pieces of all that you've talked about below and if we culled out the dead stuff and things that have been done then it would be easier for people to see what can be done. I thought I'd made those readonly, but remember now that I don't have Codehaus confluence admin privs. I've added a notice on the front page. This was already migrated to: http://cwiki.apache.org/confluence/display/MAVENOLD I can ask Ben to just shut this down. Are you done with your migration? With the intent of migrating anything meaningful into a clean slate at: http://cwiki.apache.org/confluence/display/MAVEN - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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 unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.? and settings and more
Jason van Zyl wrote: On 2009-12-30, at 6:34 PM, Brett Porter wrote: On 31/12/2009, at 2:11 AM, Jason van Zyl wrote: Arnaud, If you really want to help to let people see what's going to be planned then help cleanup this Confluence page: http://docs.codehaus.org/display/MAVEN/Home and http://docs.codehaus.org/display/MAVEN/All+Proposals There are bits and pieces of all that you've talked about below and if we culled out the dead stuff and things that have been done then it would be easier for people to see what can be done. I thought I'd made those readonly, but remember now that I don't have Codehaus confluence admin privs. I've added a notice on the front page. This was already migrated to: http://cwiki.apache.org/confluence/display/MAVENOLD I can ask Ben to just shut this down. Are you done with your migration? It would be good if it's possible to have a redirect page for the whole Codehaus wiki, that points to the new location. That'll give us, and the search engines, time to update any links to it. With the intent of migrating anything meaningful into a clean slate at: http://cwiki.apache.org/confluence/display/MAVEN - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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 unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.? and settings and more
On 31/12/2009, at 10:46 AM, Dennis Lundberg wrote: Jason van Zyl wrote: On 2009-12-30, at 6:34 PM, Brett Porter wrote: On 31/12/2009, at 2:11 AM, Jason van Zyl wrote: Arnaud, If you really want to help to let people see what's going to be planned then help cleanup this Confluence page: http://docs.codehaus.org/display/MAVEN/Home and http://docs.codehaus.org/display/MAVEN/All+Proposals There are bits and pieces of all that you've talked about below and if we culled out the dead stuff and things that have been done then it would be easier for people to see what can be done. I thought I'd made those readonly, but remember now that I don't have Codehaus confluence admin privs. I've added a notice on the front page. This was already migrated to: http://cwiki.apache.org/confluence/display/MAVENOLD I can ask Ben to just shut this down. Are you done with your migration? Looks like there have been a few modifications, and I wanted to do a better job matching up user names. Let me see if I can reimport it again and I'll drop Ben an email. It would be good if it's possible to have a redirect page for the whole Codehaus wiki, that points to the new location. That'll give us, and the search engines, time to update any links to it. Yep, I agree. I think we can point the redirect at the new wiki - if the page is migrated directly it should give a hit, and if not, Confluence will recommend the closest matching (including anything in the OLD space). There shouldn't be a need to copy over content that isn't current / reviewed. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.? and settings and more
Sure, not a problem. On 2009-12-30, at 6:46 PM, Dennis Lundberg wrote: Jason van Zyl wrote: On 2009-12-30, at 6:34 PM, Brett Porter wrote: On 31/12/2009, at 2:11 AM, Jason van Zyl wrote: Arnaud, If you really want to help to let people see what's going to be planned then help cleanup this Confluence page: http://docs.codehaus.org/display/MAVEN/Home and http://docs.codehaus.org/display/MAVEN/All+Proposals There are bits and pieces of all that you've talked about below and if we culled out the dead stuff and things that have been done then it would be easier for people to see what can be done. I thought I'd made those readonly, but remember now that I don't have Codehaus confluence admin privs. I've added a notice on the front page. This was already migrated to: http://cwiki.apache.org/confluence/display/MAVENOLD I can ask Ben to just shut this down. Are you done with your migration? It would be good if it's possible to have a redirect page for the whole Codehaus wiki, that points to the new location. That'll give us, and the search engines, time to update any links to it. With the intent of migrating anything meaningful into a clean slate at: http://cwiki.apache.org/confluence/display/MAVEN - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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 unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 2.2.2 soon?
On 30/12/2009, at 2:19 AM, Brett Porter wrote: Yep... would it be ok to just fold all those into a 3.1 version and split that into buckets later when it is being worked on, to reduce the noise? I just did that since there was only one issue in 3.1 (a dupe) and none in 3.1.alpha.2. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.? and settings and more
can we remember to update the do not use this wiki wiki to point to cwiki as well (wiki.apache.org) Sent from my [rhymes with tryPod] ;-) On 30 Dec 2009, at 23:59, Jason van Zyl ja...@sonatype.com wrote: Sure, not a problem. On 2009-12-30, at 6:46 PM, Dennis Lundberg wrote: Jason van Zyl wrote: On 2009-12-30, at 6:34 PM, Brett Porter wrote: On 31/12/2009, at 2:11 AM, Jason van Zyl wrote: Arnaud, If you really want to help to let people see what's going to be planned then help cleanup this Confluence page: http://docs.codehaus.org/display/MAVEN/Home and http://docs.codehaus.org/display/MAVEN/All+Proposals There are bits and pieces of all that you've talked about below and if we culled out the dead stuff and things that have been done then it would be easier for people to see what can be done. I thought I'd made those readonly, but remember now that I don't have Codehaus confluence admin privs. I've added a notice on the front page. This was already migrated to: http://cwiki.apache.org/confluence/display/MAVENOLD I can ask Ben to just shut this down. Are you done with your migration? It would be good if it's possible to have a redirect page for the whole Codehaus wiki, that points to the new location. That'll give us, and the search engines, time to update any links to it. With the intent of migrating anything meaningful into a clean slate at: http://cwiki.apache.org/confluence/display/MAVEN - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ --- -- 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 unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - 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 3.? and settings and more
On 31/12/2009, at 12:20 PM, Stephen Connolly wrote: can we remember to update the do not use this wiki wiki to point to cwiki as well (wiki.apache.org) I'll go one better: https://issues.apache.org/jira/browse/INFRA-2408 - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Handling Regressions in 2.x.x and flush everything forward to 3.x
I'm done reviewing 2.2.2 - all those issues can stay there. I'll work through 2.3.x, 2.2.x and 2.x as time permits (and I'm reviewing any you bump to 3.x that might be addressable there, though I don't expect any - keeping it to a small number will help ship it). On 30/12/2009, at 11:48 AM, Jason van Zyl wrote: I'm in no particular rush until the new years. I'm just slowing going through all the issues and closing out what I can. On 2009-12-29, at 7:41 PM, Brett Porter wrote: Sure, just will be slow going with some family matters to take care of today and tomorrow. On 30/12/2009, at 6:23 AM, Jason van Zyl wrote: Brett/John, Can you guys figure out what you would like to do for 2.x.x releases and flush everything else forward to 3.x? I will start scheduling some time to start ploughing through the validation in preparation for 3.0 alphas and betas. But I'll take anything you guys aren't going to handle as regressions. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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 unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Handling Regressions in 2.x.x and flush everything forward to 3.x
Sweet. On 2009-12-30, at 11:21 PM, Brett Porter wrote: I'm done reviewing 2.2.2 - all those issues can stay there. I'll work through 2.3.x, 2.2.x and 2.x as time permits (and I'm reviewing any you bump to 3.x that might be addressable there, though I don't expect any - keeping it to a small number will help ship it). On 30/12/2009, at 11:48 AM, Jason van Zyl wrote: I'm in no particular rush until the new years. I'm just slowing going through all the issues and closing out what I can. On 2009-12-29, at 7:41 PM, Brett Porter wrote: Sure, just will be slow going with some family matters to take care of today and tomorrow. On 30/12/2009, at 6:23 AM, Jason van Zyl wrote: Brett/John, Can you guys figure out what you would like to do for 2.x.x releases and flush everything else forward to 3.x? I will start scheduling some time to start ploughing through the validation in preparation for 3.0 alphas and betas. But I'll take anything you guys aren't going to handle as regressions. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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 unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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 unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
