subject:"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 2.2.2 soon?

2009-12-30 Thread Ralph Goers

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?

2009-12-30 Thread Clark, Gil W.

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

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 2.2.2 soon?

2009-12-30 Thread Brett Porter


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 2.2.2 soon?

Sent from my [rhymes with tryPod] ;-)

On 29 Dec 2009, at 05:49, Jason van Zyl ja...@sonatype.com wrote:

There are 511 issues left if you exclude the documentation fix
version. Call it 30 minutes an issue on average and that's ~250 man
hours. If we could get 10 people in January to do 25 hours (which is
a lot for most people) and try and make it easier for users to
validate fixes we might be able to pull it off in January.

between my son and his sleep deprevation torture that he is
delivering ( I connfess, son, it was I who conspired with your mother
to bring you into this world! ) and work commitments, I do not think I
will have availability before feb

- Stephen

http://jira.codehaus.org/secure/IssueNavigator.jspa?fixfor=13143fixfor=14504fixfor=16088fixfor=16089fixfor=14118fixfor=16090fixfor=16087fixfor=15103fixfor=16094fixfor=16093fixfor=15565fixfor=15472fixfor=15554fixfor=13145fixfor=13142fixfor=13141fixfor=15996fixfor=14593pid=10500status=1status=3status=4reset=trueshow=View+%26gt%3B%26gt%3B

On 2009-12-29, at 12:12 AM, Jason van Zyl wrote:

On 2009-12-28, at 10:34 PM, Brett Porter wrote:

On 29/12/2009, at 1:39 PM, Brian Fox wrote:

Is there anything pressing that calls for a 2.2.2? The 3.0's are
moving along and are quite usable.

I was just thinking of shipping the existing fixes and anything
obvious or regressed in 2.2.1.

On 29/12/2009, at 1:44 PM, Jason van Zyl wrote:

I think that the 3.x code is far enough along that if anyone is
going to do any work I think that enough work has been done in
3.x to stop working on 2.x.

So much has been fixed, tested and tuned that at this point after
using 3.x for a long time and with the tests that are in place
that I'd really like to flatten all the 2.x versions in JIRA and
toss them into the 3.x bucket. Then scour the issues and just
throw out anything that remotely looks like garbage, close things
out and get people to test against 3.x and try and get the issue
count down to the nuggets that are really going to be new
features or are really bugs.

Might as well, that's realistically the situation anyway. Nobody
is going to do major work on 2.x faced with uncertain prospects in
porting it over to 3.x. Keep anything purely specific to 2.x in
the 2.2.x bucket and move bigger stuff out.

There's not really much to port really at this point. The ITs can
always be improved but there is a pretty rock solid set of tests
there.

But we have to be 100% focused on shipping 3.0 if that's the case.
You can't put an end to 2.2.x when there's no end in sight to 3.0.

I am not interested in 2.x, but that's why I asked if anyone else
was interested in working on it. I'm not putting an end to 2.x, I'm
just not going to work on it anymore.

JIRA needs to reflect exactly what needs to be done for 3.0-
alphas, betas and final so we can start counting down. It's fair
enough to not specify a date, but at least the target needs to be
in sight to get anyone inclined to help with polishing work.

It's primarily testing work that needs to be done. The site plugin
is probably the only hole that needs to be filled as that one will
affect a lot of users.

For example, where are the issues that reflect switching to Guice
and OSGi that we keep hearing about?

Neither of those are going to happen in the 3.0 time line. We've
got Nexus running on Guice (with a Plexus shim) now and we need to
run that through the grinder for a while. When that works we can
take a look at Maven. Nexus uses almost everything in Plexus that
Maven does and we've not had to change any of code. The Plexus shim
adapts everything necessary. But we'll have to add to the shim to
account for some Maven particulars because all the old code has to
work. This is not a small job, but we've got to get Maven off
Plexus pronto. We are not attempting to do the Guice + OSGi in one
shot in Nexus and we shouldn't attempt this with Maven in one shot
either. Stuart could probably get Maven working with Guice for 3.0
but I think that would be pushing it. So I think it best to take
Guice out of the 3.0 deliverable.

The OSGi runtime will likely follow what we're doing in Nexus.
After getting Guice working as a replacement for Plexus we will
attempt to get Nexus running on Guice + Peaberry for OSGi and then
we'll run that through the grinder as well. We don't know how long
that will take, the Guice stuff is working now but the OSGi is a
whole other story. A repository of bundles doesn't really exist
(we're trying to fix that with osgi.sonatype.org) and all the
dependencies would need to be bundle-ized. So we're trying to add a
feature to Nexus to turn any JAR into a bundle on the fly. This is
fraught with problems. So I can say pretty definitively no Guice or
OSGi for 3.0, but can easily happen in a 3.1. Ultimately to users
they shouldn't notice anything, and that's just a lot of testing.

There

Re: Maven 2.2.2 soon?

As I understand it, 3.0 now consists of significant refactoring of the 
internals but no major changes externally. I originally expected 3.0 would have 
some impact on the pom schema but I don't think even that has occurred. Given 
all this is 3.0 really the appropriate version number?  I usually associate a 
change to the major release number with something that will significantly 
impact the customer.  I understand that all of this stuff is foundationally 
necessary to make some of these changes but it would seem more appropriate for 
this to be 2.5 and go to 3.0 when something significant is added that an end 
user will notice.

Ralph

On Dec 28, 2009, at 9:12 PM, Jason van Zyl wrote:

 
 On 2009-12-28, at 10:34 PM, Brett Porter wrote:
 
 
 On 29/12/2009, at 1:39 PM, Brian Fox wrote:
 
 Is there anything pressing that calls for a 2.2.2? The 3.0's are
 moving along and are quite usable.
 
 I was just thinking of shipping the existing fixes and anything obvious or 
 regressed in 2.2.1.
 
 On 29/12/2009, at 1:44 PM, Jason van Zyl wrote:
 
 I think that the 3.x code is far enough along that if anyone is going to do 
 any work I think that enough work has been done in 3.x to stop working on 
 2.x.
 
 So much has been fixed, tested and tuned that at this point after using 3.x 
 for a long time and with the tests that are in place that I'd really like 
 to flatten all the 2.x versions in JIRA and toss them into the 3.x bucket. 
 Then scour the issues and just throw out anything that remotely looks like 
 garbage, close things out and get people to test against 3.x and try and 
 get the issue count down to the nuggets that are really going to be new 
 features or are really bugs.
 
 Might as well, that's realistically the situation anyway. Nobody is going to 
 do major work on 2.x faced with uncertain prospects in porting it over to 
 3.x. Keep anything purely specific to 2.x in the 2.2.x bucket and move 
 bigger stuff out. 
 
 There's not really much to port really at this point. The ITs can always be 
 improved but there is a pretty rock solid set of tests there.
 
 
 But we have to be 100% focused on shipping 3.0 if that's the case. You can't 
 put an end to 2.2.x when there's no end in sight to 3.0.
 
 I am not interested in 2.x, but that's why I asked if anyone else was 
 interested in working on it. I'm not putting an end to 2.x, I'm just not 
 going to work on it anymore.
 
 JIRA needs to reflect exactly what needs to be done for 3.0-alphas, betas 
 and final so we can start counting down. It's fair enough to not specify a 
 date, but at least the target needs to be in sight to get anyone inclined to 
 help with polishing work.
 
 It's primarily testing work that needs to be done. The site plugin is 
 probably the only hole that needs to be filled as that one will affect a lot 
 of users.
 
 
 For example, where are the issues that reflect switching to Guice and OSGi 
 that we keep hearing about?
 
 Neither of those are going to happen in the 3.0 time line. We've got Nexus 
 running on Guice (with a Plexus shim) now and we need to run that through the 
 grinder for a while. When that works we can take a look at Maven. Nexus uses 
 almost everything in Plexus that Maven does and we've not had to change any 
 of code. The Plexus shim adapts everything necessary. But we'll have to add 
 to the shim to account for some Maven particulars because all the old code 
 has to work. This is not a small job, but we've got to get Maven off Plexus 
 pronto. We are not attempting to do the Guice + OSGi in one shot in Nexus and 
 we shouldn't attempt this with Maven in one shot either. Stuart could 
 probably get Maven working with Guice for 3.0 but I think that would be 
 pushing it. So I think it best to take Guice out of the 3.0 deliverable.
 
 The OSGi runtime will likely follow what we're doing in Nexus. After getting 
 Guice working as a replacement for Plexus we will attempt to get Nexus 
 running on Guice + Peaberry for OSGi and then we'll run that through the 
 grinder as well. We don't know how long that will take, the Guice stuff is 
 working now but the OSGi is a whole other story. A repository of bundles 
 doesn't really exist (we're trying to fix that with osgi.sonatype.org) and 
 all the dependencies would need to be bundle-ized. So we're trying to add a 
 feature to Nexus to turn any JAR into a bundle on the fly. This is fraught 
 with problems. So I can say pretty definitively no Guice or OSGi for 3.0, but 
 can easily happen in a 3.1. Ultimately to users they shouldn't notice 
 anything, and that's just a lot of testing.
 
 There is plenty to do with 3.0 without Guice and OSGi.
 
 I just added one for slf4j that you mentioned. What other things are planned 
 that are not in there so we can drive towards a goal?
 
 I think we're done to be honest. If JIRA could be trimmed down, by clearing 
 out the silliness, and starting to validate that issues marks as bugs have 
 been fixed in 3.x then that will

Re: Maven 2.2.2 soon?

+1 with Ralph. It is what I have in mind. the problem is that we already
moved from 2.1 to 3.0 and finally we should produce a 2.5 (our users will be
lost).
But I agree, 3.0 isn't a 3.0, it is 100% backward compatible with 2.X. And
more annoying we are talking about having backward incompatibilities
(removing some stuffs) in 3.1.
I'm not comfortable with that.

Cheers

Arnaud

On Tue, Dec 29, 2009 at 10:14 AM, Ralph Goers ralph.go...@dslextreme.comwrote:

 As I understand it, 3.0 now consists of significant refactoring of the
 internals but no major changes externally. I originally expected 3.0 would
 have some impact on the pom schema but I don't think even that has occurred.
 Given all this is 3.0 really the appropriate version number?  I usually
 associate a change to the major release number with something that will
 significantly impact the customer.  I understand that all of this stuff is
 foundationally necessary to make some of these changes but it would seem
 more appropriate for this to be 2.5 and go to 3.0 when something significant
 is added that an end user will notice.

 Ralph

 On Dec 28, 2009, at 9:12 PM, Jason van Zyl wrote:

 
  On 2009-12-28, at 10:34 PM, Brett Porter wrote:
 
 
  On 29/12/2009, at 1:39 PM, Brian Fox wrote:
 
  Is there anything pressing that calls for a 2.2.2? The 3.0's are
  moving along and are quite usable.
 
  I was just thinking of shipping the existing fixes and anything obvious
 or regressed in 2.2.1.
 
  On 29/12/2009, at 1:44 PM, Jason van Zyl wrote:
 
  I think that the 3.x code is far enough along that if anyone is going
 to do any work I think that enough work has been done in 3.x to stop working
 on 2.x.
 
  So much has been fixed, tested and tuned that at this point after using
 3.x for a long time and with the tests that are in place that I'd really
 like to flatten all the 2.x versions in JIRA and toss them into the 3.x
 bucket. Then scour the issues and just throw out anything that remotely
 looks like garbage, close things out and get people to test against 3.x and
 try and get the issue count down to the nuggets that are really going to be
 new features or are really bugs.
 
  Might as well, that's realistically the situation anyway. Nobody is
 going to do major work on 2.x faced with uncertain prospects in porting it
 over to 3.x. Keep anything purely specific to 2.x in the 2.2.x bucket and
 move bigger stuff out.
 
  There's not really much to port really at this point. The ITs can always
 be improved but there is a pretty rock solid set of tests there.
 
 
  But we have to be 100% focused on shipping 3.0 if that's the case. You
 can't put an end to 2.2.x when there's no end in sight to 3.0.
 
  I am not interested in 2.x, but that's why I asked if anyone else was
 interested in working on it. I'm not putting an end to 2.x, I'm just not
 going to work on it anymore.
 
  JIRA needs to reflect exactly what needs to be done for 3.0-alphas,
 betas and final so we can start counting down. It's fair enough to not
 specify a date, but at least the target needs to be in sight to get anyone
 inclined to help with polishing work.
 
  It's primarily testing work that needs to be done. The site plugin is
 probably the only hole that needs to be filled as that one will affect a lot
 of users.
 
 
  For example, where are the issues that reflect switching to Guice and
 OSGi that we keep hearing about?
 
  Neither of those are going to happen in the 3.0 time line. We've got
 Nexus running on Guice (with a Plexus shim) now and we need to run that
 through the grinder for a while. When that works we can take a look at
 Maven. Nexus uses almost everything in Plexus that Maven does and we've not
 had to change any of code. The Plexus shim adapts everything necessary. But
 we'll have to add to the shim to account for some Maven particulars because
 all the old code has to work. This is not a small job, but we've got to get
 Maven off Plexus pronto. We are not attempting to do the Guice + OSGi in one
 shot in Nexus and we shouldn't attempt this with Maven in one shot either.
 Stuart could probably get Maven working with Guice for 3.0 but I think that
 would be pushing it. So I think it best to take Guice out of the 3.0
 deliverable.
 
  The OSGi runtime will likely follow what we're doing in Nexus. After
 getting Guice working as a replacement for Plexus we will attempt to get
 Nexus running on Guice + Peaberry for OSGi and then we'll run that through
 the grinder as well. We don't know how long that will take, the Guice stuff
 is working now but the OSGi is a whole other story. A repository of bundles
 doesn't really exist (we're trying to fix that with osgi.sonatype.org) and
 all the dependencies would need to be bundle-ized. So we're trying to add a
 feature to Nexus to turn any JAR into a bundle on the fly. This is fraught
 with problems. So I can say pretty definitively no Guice or OSGi for 3.0,
 but can easily happen in a 3.1. Ultimately to users they shouldn't

Re: Maven 2.2.2 soon?

2009-12-29 Thread Mark Struberg

I think 3.0 is ok.

True, a lot projects may run out of the box without migration. But we do not 
guarantee that! Thus a 2.x number would be misleading. The '3.0' will make 
users aware that they might have to tweak their builds slightly.

Otoh, all compatibility features wie take over to 3.0 (and not explicitly 
stating it's deprectation status) will become a lot harder to remove in 3.1.

just my .02

LieGrue,
strub

--- On Tue, 12/29/09, Arnaud HERITIER aherit...@gmail.com wrote:

 From: Arnaud HERITIER aherit...@gmail.com
 Subject: Re: Maven 2.2.2 soon?
 To: Maven Developers List dev@maven.apache.org
 Date: Tuesday, December 29, 2009, 10:18 AM
 +1 with Ralph. It is what I have in
 mind. the problem is that we already
 moved from 2.1 to 3.0 and finally we should produce a 2.5
 (our users will be
 lost).
 But I agree, 3.0 isn't a 3.0, it is 100% backward
 compatible with 2.X. And
 more annoying we are talking about having backward
 incompatibilities
 (removing some stuffs) in 3.1.
 I'm not comfortable with that.
 
 Cheers
 
 Arnaud
 
 On Tue, Dec 29, 2009 at 10:14 AM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:
 
  As I understand it, 3.0 now consists of significant
 refactoring of the
  internals but no major changes externally. I
 originally expected 3.0 would
  have some impact on the pom schema but I don't think
 even that has occurred.
  Given all this is 3.0 really the appropriate version
 number?  I usually
  associate a change to the major release number with
 something that will
  significantly impact the customer.  I understand
 that all of this stuff is
  foundationally necessary to make some of these changes
 but it would seem
  more appropriate for this to be 2.5 and go to 3.0 when
 something significant
  is added that an end user will notice.
 
  Ralph
 
  On Dec 28, 2009, at 9:12 PM, Jason van Zyl wrote:
 
  
   On 2009-12-28, at 10:34 PM, Brett Porter wrote:
  
  
   On 29/12/2009, at 1:39 PM, Brian Fox wrote:
  
   Is there anything pressing that calls for
 a 2.2.2? The 3.0's are
   moving along and are quite usable.
  
   I was just thinking of shipping the existing
 fixes and anything obvious
  or regressed in 2.2.1.
  
   On 29/12/2009, at 1:44 PM, Jason van Zyl
 wrote:
  
   I think that the 3.x code is far enough
 along that if anyone is going
  to do any work I think that enough work has been done
 in 3.x to stop working
  on 2.x.
  
   So much has been fixed, tested and tuned
 that at this point after using
  3.x for a long time and with the tests that are in
 place that I'd really
  like to flatten all the 2.x versions in JIRA and toss
 them into the 3.x
  bucket. Then scour the issues and just throw out
 anything that remotely
  looks like garbage, close things out and get people to
 test against 3.x and
  try and get the issue count down to the nuggets that
 are really going to be
  new features or are really bugs.
  
   Might as well, that's realistically the
 situation anyway. Nobody is
  going to do major work on 2.x faced with uncertain
 prospects in porting it
  over to 3.x. Keep anything purely specific to 2.x in
 the 2.2.x bucket and
  move bigger stuff out.
  
   There's not really much to port really at this
 point. The ITs can always
  be improved but there is a pretty rock solid set of
 tests there.
  
  
   But we have to be 100% focused on shipping
 3.0 if that's the case. You
  can't put an end to 2.2.x when there's no end in sight
 to 3.0.
  
   I am not interested in 2.x, but that's why I
 asked if anyone else was
  interested in working on it. I'm not putting an end to
 2.x, I'm just not
  going to work on it anymore.
  
   JIRA needs to reflect exactly what needs to
 be done for 3.0-alphas,
  betas and final so we can start counting down. It's
 fair enough to not
  specify a date, but at least the target needs to be in
 sight to get anyone
  inclined to help with polishing work.
  
   It's primarily testing work that needs to be
 done. The site plugin is
  probably the only hole that needs to be filled as that
 one will affect a lot
  of users.
  
  
   For example, where are the issues that
 reflect switching to Guice and
  OSGi that we keep hearing about?
  
   Neither of those are going to happen in the 3.0
 time line. We've got
  Nexus running on Guice (with a Plexus shim) now and we
 need to run that
  through the grinder for a while. When that works we
 can take a look at
  Maven. Nexus uses almost everything in Plexus that
 Maven does and we've not
  had to change any of code. The Plexus shim adapts
 everything necessary. But
  we'll have to add to the shim to account for some
 Maven particulars because
  all the old code has to work. This is not a small job,
 but we've got to get
  Maven off Plexus pronto. We are not attempting to do
 the Guice + OSGi in one
  shot in Nexus and we shouldn't attempt this with Maven
 in one shot either.
  Stuart could probably get Maven working with Guice for
 3.0 but I think that
  would be pushing it. So I think

Re: Maven 2.2.2 soon?

2009-12-29 Thread Benjamin Bentmann


Brett Porter wrote:


[...] or reasons not to move forward with releasing?


The changes for MNG-4148, see [0] for the former discussion.


Benjamin


[0] http://www.mail-archive.com/dev@maven.apache.org/msg82166.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 29/12/2009, at 4:12 PM, Jason van Zyl wrote:

 
 For example, where are the issues that reflect switching to Guice and OSGi 
 that we keep hearing about?
 
 Neither of those are going to happen in the 3.0 time line.

Ok, I think there has been some confusion on this and other parts in terms of 
timing. It makes it much easier to understand where things are going if the 
JIRA roadmap (post-cleanup) reflects reality.

 I just added one for slf4j that you mentioned. What other things are planned 
 that are not in there so we can drive towards a goal?
 
 I think we're done to be honest. If JIRA could be trimmed down, by clearing 
 out the silliness, and starting to validate that issues marks as bugs have 
 been fixed in 3.x then that will get us most of the way there. For what 
 remains trying to bug fix and write ITs is really the only thing left I 
 really want to tackle. 

+1

 
 Using SLF4J as the API will really amount to working over time at injecting a 
 logger with the SLF4J API instead of the Plexus API one. At very least maybe 
 we can cleanup the Plexus SLF4J stuff so that if we do provide a way to 
 configure the logging using standard SLF4J stuff it won't change when we 
 change the API internally. We are doing a lot of logging and tracing work in 
 Nexus and M2Eclipse right now so some of this might fall out of that and go 
 back into Maven but if someone else wants to tackle that it would be cool.

I've mucked with this a number of times to unify things so don't mind working 
on it, but it seems more like a 3.1 thing to tackle because of the 
repercussions it might have. Also, doesn't OSGi provide logging facilities that 
it might be better to take advantage of if it is going to be there?

 
 
 I'd also avoid planning 3.1 alphas at this stage. Focus on getting 3.0 out, 
 and everything else that is after 3.0 can be up for grabs.
 
 
 There I'm only trying to collect things that we cannot change in 3.0. If I've 
 seen things like POM changes I've just been pushing it into 3.0.alpha1.

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?

Cheers,
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 2.2.2 soon?


On 29/12/2009, at 8:18 PM, Arnaud HERITIER wrote:

 +1 with Ralph. It is what I have in mind. the problem is that we already
 moved from 2.1 to 3.0 and finally we should produce a 2.5 (our users will be
 lost).
 But I agree, 3.0 isn't a 3.0, it is 100% backward compatible with 2.X. And
 more annoying we are talking about having backward incompatibilities
 (removing some stuffs) in 3.1.
 I'm not comfortable with that.

I tend to agree, but I think the target has moved so much, especially with a 
lot of public talks about the versions, that changing anything might cause 
further confusion.

What about something like this:
- 2.3 (or 2.9?) release that just adds all the deprecations (kind of like what 
Lucene did before a major rev).
- 3.0 release retains deprecated functionality, with a --strict mode to fail 
instead of warning (I haven't seen this, but ISTR Brian saying this was going 
to be added, or is already there, at ApacheCon)
- 3.1 can then drop the functionality

So, 3.0 essentially drops the functionality, with a grace period - which is 
closer to what users might expect without changing the current story.

WDYT?

- 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 2.2.2 soon?


On 29/12/2009, at 4:49 PM, Jason van Zyl wrote:

 There are 511 issues left if you exclude the documentation fix version. Call 
 it 30 minutes an issue on average and that's ~250 man hours. If we could get 
 10 people in January to do 25 hours (which is a lot for most people) and try 
 and make it easier for users to validate fixes we might be able to pull it 
 off in January.
 
 http://jira.codehaus.org/secure/IssueNavigator.jspa?fixfor=13143fixfor=14504fixfor=16088fixfor=16089fixfor=14118fixfor=16090fixfor=16087fixfor=15103fixfor=16094fixfor=16093fixfor=15565fixfor=15472fixfor=15554fixfor=13145fixfor=13142fixfor=13141fixfor=15996fixfor=14593pid=10500status=1status=3status=4reset=trueshow=View+%26gt%3B%26gt%3B
 

I tend to work through the unscheduled issues every now and then, since it 
makes it easier to find the new stuff that comes in. I can focus on starting 
there.

I've liked having a Backlog version for things that are reviewed and may be 
fixed in the future, without committing to a version/series. Could we create 
that to start pushing valid issues into so they don't get reviewed twice? The 
goal is then to get rid of the *.x versions. Alternatively we could just 
unschedule them all and push them to the 3.x bucket.

The criteria being:
- regressions in 2.1.x/2.2.x - 2.2.2
- regressions in 3.0-alpha-X - 3.0-alpha-7
- very select number new features and improvements - 3.1
- everything else that is still valid - Backlog

Right?

Cheers,
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 2.2.2 soon?


On 2009-12-29, at 4:14 AM, Ralph Goers wrote:

 As I understand it, 3.0 now consists of significant refactoring of the 
 internals but no major changes externally.

This was decided after how much work we've done I figured trying to bring the 
community forward on a version of Maven that was a real replacement was more 
important. By a real replacement I mean one that can be patched, is easier to 
navigate at the source level, have better tests, and remove some of the 
architectural problems that would prevent building interesting features that we 
want in the future. This took a lot of work and I think pushing out POM changes 
and potential interoperability problems just isn't worth it. The message is 
Maven 3.x is a drop in replacement and we'll build upon that for the future.

 I originally expected 3.0 would have some impact on the pom schema but I 
 don't think even that has occurred. Given all this is 3.0 really the 
 appropriate version number?  I usually associate a change to the major 
 release number with something that will significantly impact the customer.  I 
 understand that all of this stuff is foundationally necessary to make some of 
 these changes but it would seem more appropriate for this to be 2.5 and go to 
 3.0 when something significant is added that an end user will notice.
 

No, I think 3.0 is appropriate. Just the embedder changes alone there are 
radical API changes. From the CLI perspective users aren't going to notice 
much. At least they shouldn't. But all the new m2eclipse relies on all these 
changed APIs and the Polyglot Maven in the works is also dependent on all those 
changes. It's significant enough at the API level to call it 3.0.

 Ralph
 
 On Dec 28, 2009, at 9:12 PM, Jason van Zyl wrote:
 
 
 On 2009-12-28, at 10:34 PM, Brett Porter wrote:
 
 
 On 29/12/2009, at 1:39 PM, Brian Fox wrote:
 
 Is there anything pressing that calls for a 2.2.2? The 3.0's are
 moving along and are quite usable.
 
 I was just thinking of shipping the existing fixes and anything obvious or 
 regressed in 2.2.1.
 
 On 29/12/2009, at 1:44 PM, Jason van Zyl wrote:
 
 I think that the 3.x code is far enough along that if anyone is going to 
 do any work I think that enough work has been done in 3.x to stop working 
 on 2.x.
 
 So much has been fixed, tested and tuned that at this point after using 
 3.x for a long time and with the tests that are in place that I'd really 
 like to flatten all the 2.x versions in JIRA and toss them into the 3.x 
 bucket. Then scour the issues and just throw out anything that remotely 
 looks like garbage, close things out and get people to test against 3.x 
 and try and get the issue count down to the nuggets that are really going 
 to be new features or are really bugs.
 
 Might as well, that's realistically the situation anyway. Nobody is going 
 to do major work on 2.x faced with uncertain prospects in porting it over 
 to 3.x. Keep anything purely specific to 2.x in the 2.2.x bucket and move 
 bigger stuff out. 
 
 There's not really much to port really at this point. The ITs can always be 
 improved but there is a pretty rock solid set of tests there.
 
 
 But we have to be 100% focused on shipping 3.0 if that's the case. You 
 can't put an end to 2.2.x when there's no end in sight to 3.0.
 
 I am not interested in 2.x, but that's why I asked if anyone else was 
 interested in working on it. I'm not putting an end to 2.x, I'm just not 
 going to work on it anymore.
 
 JIRA needs to reflect exactly what needs to be done for 3.0-alphas, betas 
 and final so we can start counting down. It's fair enough to not specify a 
 date, but at least the target needs to be in sight to get anyone inclined 
 to help with polishing work.
 
 It's primarily testing work that needs to be done. The site plugin is 
 probably the only hole that needs to be filled as that one will affect a lot 
 of users.
 
 
 For example, where are the issues that reflect switching to Guice and OSGi 
 that we keep hearing about?
 
 Neither of those are going to happen in the 3.0 time line. We've got Nexus 
 running on Guice (with a Plexus shim) now and we need to run that through 
 the grinder for a while. When that works we can take a look at Maven. Nexus 
 uses almost everything in Plexus that Maven does and we've not had to change 
 any of code. The Plexus shim adapts everything necessary. But we'll have to 
 add to the shim to account for some Maven particulars because all the old 
 code has to work. This is not a small job, but we've got to get Maven off 
 Plexus pronto. We are not attempting to do the Guice + OSGi in one shot in 
 Nexus and we shouldn't attempt this with Maven in one shot either. Stuart 
 could probably get Maven working with Guice for 3.0 but I think that would 
 be pushing it. So I think it best to take Guice out of the 3.0 deliverable.
 
 The OSGi runtime will likely follow what we're doing in Nexus. After getting 
 Guice working as a replacement for Plexus we will

Re: Maven 2.2.2 soon?

It's completely different at an API level, and not compatible. It's not just a 
tool anymore, it's more like a library and it resembles almost nothing to the 
2.x codebase.

On 2009-12-29, at 4:18 AM, Arnaud HERITIER wrote:

 +1 with Ralph. It is what I have in mind. the problem is that we already
 moved from 2.1 to 3.0 and finally we should produce a 2.5 (our users will be
 lost).
 But I agree, 3.0 isn't a 3.0, it is 100% backward compatible with 2.X. And
 more annoying we are talking about having backward incompatibilities
 (removing some stuffs) in 3.1.
 I'm not comfortable with that.
 
 Cheers
 
 Arnaud
 
 On Tue, Dec 29, 2009 at 10:14 AM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:
 
 As I understand it, 3.0 now consists of significant refactoring of the
 internals but no major changes externally. I originally expected 3.0 would
 have some impact on the pom schema but I don't think even that has occurred.
 Given all this is 3.0 really the appropriate version number?  I usually
 associate a change to the major release number with something that will
 significantly impact the customer.  I understand that all of this stuff is
 foundationally necessary to make some of these changes but it would seem
 more appropriate for this to be 2.5 and go to 3.0 when something significant
 is added that an end user will notice.
 
 Ralph
 
 On Dec 28, 2009, at 9:12 PM, Jason van Zyl wrote:
 
 
 On 2009-12-28, at 10:34 PM, Brett Porter wrote:
 
 
 On 29/12/2009, at 1:39 PM, Brian Fox wrote:
 
 Is there anything pressing that calls for a 2.2.2? The 3.0's are
 moving along and are quite usable.
 
 I was just thinking of shipping the existing fixes and anything obvious
 or regressed in 2.2.1.
 
 On 29/12/2009, at 1:44 PM, Jason van Zyl wrote:
 
 I think that the 3.x code is far enough along that if anyone is going
 to do any work I think that enough work has been done in 3.x to stop working
 on 2.x.
 
 So much has been fixed, tested and tuned that at this point after using
 3.x for a long time and with the tests that are in place that I'd really
 like to flatten all the 2.x versions in JIRA and toss them into the 3.x
 bucket. Then scour the issues and just throw out anything that remotely
 looks like garbage, close things out and get people to test against 3.x and
 try and get the issue count down to the nuggets that are really going to be
 new features or are really bugs.
 
 Might as well, that's realistically the situation anyway. Nobody is
 going to do major work on 2.x faced with uncertain prospects in porting it
 over to 3.x. Keep anything purely specific to 2.x in the 2.2.x bucket and
 move bigger stuff out.
 
 There's not really much to port really at this point. The ITs can always
 be improved but there is a pretty rock solid set of tests there.
 
 
 But we have to be 100% focused on shipping 3.0 if that's the case. You
 can't put an end to 2.2.x when there's no end in sight to 3.0.
 
 I am not interested in 2.x, but that's why I asked if anyone else was
 interested in working on it. I'm not putting an end to 2.x, I'm just not
 going to work on it anymore.
 
 JIRA needs to reflect exactly what needs to be done for 3.0-alphas,
 betas and final so we can start counting down. It's fair enough to not
 specify a date, but at least the target needs to be in sight to get anyone
 inclined to help with polishing work.
 
 It's primarily testing work that needs to be done. The site plugin is
 probably the only hole that needs to be filled as that one will affect a lot
 of users.
 
 
 For example, where are the issues that reflect switching to Guice and
 OSGi that we keep hearing about?
 
 Neither of those are going to happen in the 3.0 time line. We've got
 Nexus running on Guice (with a Plexus shim) now and we need to run that
 through the grinder for a while. When that works we can take a look at
 Maven. Nexus uses almost everything in Plexus that Maven does and we've not
 had to change any of code. The Plexus shim adapts everything necessary. But
 we'll have to add to the shim to account for some Maven particulars because
 all the old code has to work. This is not a small job, but we've got to get
 Maven off Plexus pronto. We are not attempting to do the Guice + OSGi in one
 shot in Nexus and we shouldn't attempt this with Maven in one shot either.
 Stuart could probably get Maven working with Guice for 3.0 but I think that
 would be pushing it. So I think it best to take Guice out of the 3.0
 deliverable.
 
 The OSGi runtime will likely follow what we're doing in Nexus. After
 getting Guice working as a replacement for Plexus we will attempt to get
 Nexus running on Guice + Peaberry for OSGi and then we'll run that through
 the grinder as well. We don't know how long that will take, the Guice stuff
 is working now but the OSGi is a whole other story. A repository of bundles
 doesn't really exist (we're trying to fix that with osgi.sonatype.org) and
 all the dependencies would need to be bundle-ized. So we're trying to

Re: Maven 2.2.2 soon?

On 2009-12-29, at 10:33 AM, Brett Porter wrote:

On 29/12/2009, at 4:49 PM, Jason van Zyl wrote:

There are 511 issues left if you exclude the documentation fix version. Call
it 30 minutes an issue on average and that's ~250 man hours. If we could get
10 people in January to do 25 hours (which is a lot for most people) and try
and make it easier for users to validate fixes we might be able to pull it
off in January.

I tend to work through the unscheduled issues every now and then, since it
makes it easier to find the new stuff that comes in. I can focus on starting
there.

I've liked having a Backlog version for things that are reviewed and may be
fixed in the future, without committing to a version/series. Could we create
that to start pushing valid issues into so they don't get reviewed twice? The
goal is then to get rid of the *.x versions. Alternatively we could just
unschedule them all and push them to the 3.x bucket.

The criteria being:
- regressions in 2.1.x/2.2.x - 2.2.2
- regressions in 3.0-alpha-X - 3.0-alpha-7
- very select number new features and improvements - 3.1
- everything else that is still valid - Backlog

Right?

Whatever you guys are going to fix in 2.x.x keep it in those versions. If
you're not then flush them forward into 3.x so that we can start validating
them against 3.0 to see if they are fixed or truly need to be addressed.

Anything requiring POM changes that look reasonably interesting I've been
putting in 3.0.alpha1.

But in all honesty we should get down to less then 50 issues or we're never
going to be able to manage them.

I think just trying to validate what's there against the 3.0 alphas will get
rid of a lot of cruft. I think if we start there we'll be in good shape.

Cheers,
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 2.2.2 soon?


On Dec 29, 2009, at 7:40 AM, Jason van Zyl wrote:

 
 On 2009-12-29, at 4:14 AM, Ralph Goers wrote:
 
 As I understand it, 3.0 now consists of significant refactoring of the 
 internals but no major changes externally.
 
 This was decided after how much work we've done I figured trying to bring the 
 community forward on a version of Maven that was a real replacement was more 
 important. By a real replacement I mean one that can be patched, is easier to 
 navigate at the source level, have better tests, and remove some of the 
 architectural problems that would prevent building interesting features that 
 we want in the future. This took a lot of work and I think pushing out POM 
 changes and potential interoperability problems just isn't worth it. The 
 message is Maven 3.x is a drop in replacement and we'll build upon that for 
 the future.

I didn't mean it as a criticism. Just that 3.0 started out with one target in 
mind and is now something completely different. 

At some point we HAVE to do something about making the pom extensible. It just 
doesn't contain enough information to solve some of the problems. This could be 
done if Maven would tolerate stuff it doesn't understand. It would be best if 
this could be done sooner rather than later. i.e., that alone would justify a 
2.2 release.

Since I haven't done any of the work on 3.0 I'm not going to make a big deal 
out of what the version number of the release should be.

Ralph
-
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 Tue, Dec 29, 2009 at 4:24 PM, Brett Porter br...@apache.org wrote:


 On 29/12/2009, at 8:18 PM, Arnaud HERITIER wrote:

  +1 with Ralph. It is what I have in mind. the problem is that we already
  moved from 2.1 to 3.0 and finally we should produce a 2.5 (our users will
 be
  lost).
  But I agree, 3.0 isn't a 3.0, it is 100% backward compatible with 2.X.
 And
  more annoying we are talking about having backward incompatibilities
  (removing some stuffs) in 3.1.
  I'm not comfortable with that.

 I tend to agree, but I think the target has moved so much, especially with
 a lot of public talks about the versions, that changing anything might cause
 further confusion.


yes. it's impossible to change.



 What about something like this:
 - 2.3 (or 2.9?) release that just adds all the deprecations (kind of like
 what Lucene did before a major rev).
 - 3.0 release retains deprecated functionality, with a --strict mode to
 fail instead of warning (I haven't seen this, but ISTR Brian saying this was
 going to be added, or is already there, at ApacheCon)
 - 3.1 can then drop the functionality

 So, 3.0 essentially drops the functionality, with a grace period - which
 is closer to what users might expect without changing the current story.


+1, with the strict mode activated by default in 3.0. We could have an
option in settings.xml to deactivate it for example.


 WDYT?


I agree. The problem will be in 3.1. We'll be able to remove things
deprecated in 3.0 but nothing more.
We'll have to see what we'll do if we have big changes.
For me the most important problem to work on (post 3.0), will be how we
manage different versions of POMs and metadata. This will have an important
impact for our users.

cheers,


 - 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 2.2.2 soon?

2009/12/29 Arnaud HERITIER aherit...@gmail.com

 On Tue, Dec 29, 2009 at 4:24 PM, Brett Porter br...@apache.org wrote:

 
  On 29/12/2009, at 8:18 PM, Arnaud HERITIER wrote:
 
   +1 with Ralph. It is what I have in mind. the problem is that we
 already
   moved from 2.1 to 3.0 and finally we should produce a 2.5 (our users
 will
  be
   lost).
   But I agree, 3.0 isn't a 3.0, it is 100% backward compatible with 2.X.
  And
   more annoying we are talking about having backward incompatibilities
   (removing some stuffs) in 3.1.
   I'm not comfortable with that.
 
  I tend to agree, but I think the target has moved so much, especially
 with
  a lot of public talks about the versions, that changing anything might
 cause
  further confusion.
 

 yes. it's impossible to change.


 
  What about something like this:
  - 2.3 (or 2.9?) release that just adds all the deprecations (kind of like
  what Lucene did before a major rev).
  - 3.0 release retains deprecated functionality, with a --strict mode to
  fail instead of warning (I haven't seen this, but ISTR Brian saying this
 was
  going to be added, or is already there, at ApacheCon)
  - 3.1 can then drop the functionality
 
  So, 3.0 essentially drops the functionality, with a grace period -
 which
  is closer to what users might expect without changing the current story.
 

 +1, with the strict mode activated by default in 3.0. We could have an
 option in settings.xml to deactivate it for example.

 
  WDYT?
 

 I agree. The problem will be in 3.1. We'll be able to remove things
 deprecated in 3.0 but nothing more.
 We'll have to see what we'll do if we have big changes.
 For me the most important problem to work on (post 3.0), will be how we
 manage different versions of POMs and metadata. This will have an important
 impact for our users.

 cheers,


I think this depends on what model changes we want.

My Idea is to deploy the new version pom as a pom with a classifier and
co-deploy a v4.0.0 translated pom as the pom without a classifier.

That way we can have m4 look for the pom with classifier (if missing it
looks for the v4.0.0 pom) everything older will only see the pom without a
classifier

-Stephen

P.S. I think Brian Fox had a similar idea


 
  - 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 2.2.2 soon?


On 2009-12-29, at 11:25 AM, Ralph Goers wrote:

 
 On Dec 29, 2009, at 7:40 AM, Jason van Zyl wrote:
 
 
 On 2009-12-29, at 4:14 AM, Ralph Goers wrote:
 
 As I understand it, 3.0 now consists of significant refactoring of the 
 internals but no major changes externally.
 
 This was decided after how much work we've done I figured trying to bring 
 the community forward on a version of Maven that was a real replacement was 
 more important. By a real replacement I mean one that can be patched, is 
 easier to navigate at the source level, have better tests, and remove some 
 of the architectural problems that would prevent building interesting 
 features that we want in the future. This took a lot of work and I think 
 pushing out POM changes and potential interoperability problems just isn't 
 worth it. The message is Maven 3.x is a drop in replacement and we'll build 
 upon that for the future.
 
 I didn't mean it as a criticism. Just that 3.0 started out with one target in 
 mind and is now something completely different. 
 

Not really. Most of what we want to do now is possible. It's not technically 
hard to make POM changes at this point, but it's more a matter of the 
interoperability plan and our ability to test. But the internals are very 
different. 

 At some point we HAVE to do something about making the pom extensible. It 
 just doesn't contain enough information to solve some of the problems. This 
 could be done if Maven would tolerate stuff it doesn't understand. It would 
 be best if this could be done sooner rather than later. i.e., that alone 
 would justify a 2.2 release.
 

Yes, but I don't think anyone understands how hard this actually is. The 3.0 
internals will allow this now, that's not actually a technical problem anymore.

 Since I haven't done any of the work on 3.0 I'm not going to make a big deal 
 out of what the version number of the release should be.
 

I honestly think it will be easier for people to get involved in the 3.0 
codebase.

 Ralph
 -
 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?



  
 
  I agree. The problem will be in 3.1. We'll be able to remove things
  deprecated in 3.0 but nothing more.
  We'll have to see what we'll do if we have big changes.
  For me the most important problem to work on (post 3.0), will be how we
  manage different versions of POMs and metadata. This will have an
 important
  impact for our users.
 
  cheers,
 
 
 I think this depends on what model changes we want.

 My Idea is to deploy the new version pom as a pom with a classifier and
 co-deploy a v4.0.0 translated pom as the pom without a classifier.

 That way we can have m4 look for the pom with classifier (if missing it
 looks for the v4.0.0 pom) everything older will only see the pom without a
 classifier

 -Stephen

 P.S. I think Brian Fox had a similar idea


 In the future if we have 4.0.0, 4.1.0, 4.2.0 ... models, we'll try to
deploy one per version with a different classifier ?
And what will happen when we'll do a change in a model that we cannot
convert to 4.0.0 model? We don't deploy it ?

Arnaud

Re: Maven 2.2.2 soon?


On 2009-12-29, at 11:54 AM, Arnaud HERITIER wrote:

 
 
 
 
 I agree. The problem will be in 3.1. We'll be able to remove things
 deprecated in 3.0 but nothing more.
 We'll have to see what we'll do if we have big changes.
 For me the most important problem to work on (post 3.0), will be how we
 manage different versions of POMs and metadata. This will have an
 important
 impact for our users.
 
 cheers,
 
 
 I think this depends on what model changes we want.
 
 My Idea is to deploy the new version pom as a pom with a classifier and
 co-deploy a v4.0.0 translated pom as the pom without a classifier.
 
 That way we can have m4 look for the pom with classifier (if missing it
 looks for the v4.0.0 pom) everything older will only see the pom without a
 classifier
 
 -Stephen
 
 P.S. I think Brian Fox had a similar idea
 
 
 In the future if we have 4.0.0, 4.1.0, 4.2.0 ... models, we'll try to
 deploy one per version with a different classifier ?
 And what will happen when we'll do a change in a model that we cannot
 convert to 4.0.0 model? We don't deploy it ?
 

Trust me, we'll be talking about this for a while. If it's simply binary 
consumption it's the dependencies that matter and the 4.0.0 of the POM can 
probably be used forever, that's not really a big deal. But I think we have to 
take a larger view here with respect to projects that want to rebuild projects 
from source, integrating 3rd party tools, and syncing this up with metadata 
changes that might happen in the repository. 

But I really think this is going to be done in a branching by abstraction 
fashion and it's just all going to have to work in the trunk. We just can't 
ever afford to go off into branches because this developer community cannot 
support it.

 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

Re: Maven 2.2.2 soon?

2009/12/29 Arnaud HERITIER aherit...@gmail.com

 
 
   
  
   I agree. The problem will be in 3.1. We'll be able to remove things
   deprecated in 3.0 but nothing more.
   We'll have to see what we'll do if we have big changes.
   For me the most important problem to work on (post 3.0), will be how we
   manage different versions of POMs and metadata. This will have an
  important
   impact for our users.
  
   cheers,
  
  
  I think this depends on what model changes we want.
 
  My Idea is to deploy the new version pom as a pom with a classifier and
  co-deploy a v4.0.0 translated pom as the pom without a classifier.
 
  That way we can have m4 look for the pom with classifier (if missing it
  looks for the v4.0.0 pom) everything older will only see the pom without
 a
  classifier
 
  -Stephen
 
  P.S. I think Brian Fox had a similar idea
 
 
  In the future if we have 4.0.0, 4.1.0, 4.2.0 ... models, we'll try to
 deploy one per version with a different classifier ?
 And what will happen when we'll do a change in a model that we cannot
 convert to 4.0.0 model? We don't deploy it ?


We deploy the dependencies as the 4.0.0 model, we strip out the parent info
and fully resolve the pom for the 4.0.0 model

For the pom with classifier, we use a scheme that allows us to plug in
extensibility so that we only need one classifer ever... we call the
classifier build and the pom without classifier is just for dependency
info


 Arnaud

Re: Maven 2.2.2 soon?


On Dec 29, 2009, at 8:28 AM, Arnaud HERITIER wrote:

 
 I agree. The problem will be in 3.1. We'll be able to remove things
 deprecated in 3.0 but nothing more.
 We'll have to see what we'll do if we have big changes.
 For me the most important problem to work on (post 3.0), will be how we
 manage different versions of POMs and metadata. This will have an important
 impact for our users.
 

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.

Ralph
-
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?

2009-12-29 Thread Brian Fox

I 100% agree that the pom format is likely the single biggest thing we
need to tackle in the future. What that means for future maven
versions is unclear since I agree that pom changes would justify a
major version bump although I don't think we want to talk about 4.x.

However I definitely think that this version belongs as 3.x, there are
enough changes to justify it, and the fact that it's all new code
means we shouldn't hide it under 2.x.


On Tue, Dec 29, 2009 at 1:24 PM, Ralph Goers ralph.go...@dslextreme.com wrote:

 On Dec 29, 2009, at 8:28 AM, Arnaud HERITIER wrote:


 I agree. The problem will be in 3.1. We'll be able to remove things
 deprecated in 3.0 but nothing more.
 We'll have to see what we'll do if we have big changes.
 For me the most important problem to work on (post 3.0), will be how we
 manage different versions of POMs and metadata. This will have an important
 impact for our users.


 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.

 Ralph
 -
 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?

2009/12/29 Brian Fox bri...@infinity.nu

 I 100% agree that the pom format is likely the single biggest thing we
 need to tackle in the future. What that means for future maven
 versions is unclear since I agree that pom changes would justify a
 major version bump although I don't think we want to talk about 4.x.


well it would make more sense to call it 5.x and skip 4.x entirely since the
model version is already at 4.0.0 ;-)


 However I definitely think that this version belongs as 3.x, there are
 enough changes to justify it, and the fact that it's all new code
 means we shouldn't hide it under 2.x.


 On Tue, Dec 29, 2009 at 1:24 PM, Ralph Goers ralph.go...@dslextreme.com
 wrote:
 
  On Dec 29, 2009, at 8:28 AM, Arnaud HERITIER wrote:
 
 
  I agree. The problem will be in 3.1. We'll be able to remove things
  deprecated in 3.0 but nothing more.
  We'll have to see what we'll do if we have big changes.
  For me the most important problem to work on (post 3.0), will be how we
  manage different versions of POMs and metadata. This will have an
 important
  impact for our users.
 
 
  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.
 
  Ralph
  -
  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 Tuesday, December 29, 2009, Jason van Zyl ja...@sonatype.com wrote:

 On 2009-12-29, at 11:54 AM, Arnaud HERITIER wrote:





 I agree. The problem will be in 3.1. We'll be able to remove things
 deprecated in 3.0 but nothing more.
 We'll have to see what we'll do if we have big changes.
 For me the most important problem to work on (post 3.0), will be how we
 manage different versions of POMs and metadata. This will have an
 important
 impact for our users.

 cheers,


 I think this depends on what model changes we want.

 My Idea is to deploy the new version pom as a pom with a classifier and
 co-deploy a v4.0.0 translated pom as the pom without a classifier.

 That way we can have m4 look for the pom with classifier (if missing it
 looks for the v4.0.0 pom) everything older will only see the pom without a
 classifier

 -Stephen

 P.S. I think Brian Fox had a similar idea


 In the future if we have 4.0.0, 4.1.0, 4.2.0 ... models, we'll try to
 deploy one per version with a different classifier ?
 And what will happen when we'll do a change in a model that we cannot
 convert to 4.0.0 model? We don't deploy it ?


 Trust me, we'll be talking about this for a while. If it's simply binary 
 consumption it's the dependencies that matter and the 4.0.0 of the POM can 
 probably be used forever, that's not really a big deal. But I think we have 
 to take a larger view here with respect to projects that want to rebuild 
 projects from source, integrating 3rd party tools, and syncing this up with 
 metadata changes that might happen in the repository.

 But I really think this is going to be done in a branching by abstraction 
 fashion and it's just all going to have to work in the trunk. We just can't 
 ever afford to go off into branches because this developer community cannot 
 support it.


I trust you ;). I'm just doing the advocate of devil.

For dependencies I agree it is easy. But not too easy. We already
broke backward compat with the import scope in 2.0.9

I think the problem will be more for inheritence (and perhaps mixins) ?


 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



-- 
Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net

-
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 5:24 AM, Ralph Goers wrote:

 
 On Dec 29, 2009, at 8:28 AM, Arnaud HERITIER wrote:
 
 
 I agree. The problem will be in 3.1. We'll be able to remove things
 deprecated in 3.0 but nothing more.
 We'll have to see what we'll do if we have big changes.
 For me the most important problem to work on (post 3.0), will be how we
 manage different versions of POMs and metadata. This will have an important
 impact for our users.
 
 
 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.

- 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 2.2.2 soon?


  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.
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.

Another question about 3.0, did we reintroduce // dowloads ? I think it
wasn't here in the last alpha.

Arnaud

Re: Maven 2.2.2 soon?

2009-12-29 Thread Paul Benedict

I think Maven POMs should be like the rules governing HTML and CSS
versions. Ignore tags and attributes you don't know and interpret what
you can. Allow graceful degration of behavior so those who want to
publish 4.1 POMs can still be used with 4.0 readers.

On Tue, Dec 29, 2009 at 7:05 PM, Arnaud HERITIER aherit...@gmail.com 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.
 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.

 Another question about 3.0, did we reintroduce // dowloads ? I think it
 wasn't here in the last alpha.

 Arnaud


-
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 Dec 29, 2009, at 6:22 PM, Paul Benedict wrote:

 I think Maven POMs should be like the rules governing HTML and CSS
 versions. Ignore tags and attributes you don't know and interpret what
 you can. Allow graceful degration of behavior so those who want to
 publish 4.1 POMs can still be used with 4.0 readers.

Graceful degradation doesn't work. 4.0 is strict. Maven 2.x won't handle 
anything undefined. The only reasonable solution is that the new project 
descriptor won't be a pom.xml.  pom.xml will always be reserved for a 2.x 
compatible POM. 

The new project descriptor should allow for enhancement. One of the things we 
should discuss and agree on is how that will work. There is an advantage to 
having a schema for validation, but logical extension points need to be 
allowed. This would also be a great time to make the new descriptor less 
verbose.

Ralph


 
 On Tue, Dec 29, 2009 at 7:05 PM, Arnaud HERITIER aherit...@gmail.com 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.
 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.
 
 Another question about 3.0, did we reintroduce // dowloads ? I think it
 wasn't here in the last alpha.
 
 Arnaud
 
 
 -
 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-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.

 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

Re: Maven 2.2.2 soon?

2009-12-29 Thread Paul Benedict

On Tue, Dec 29, 2009 at 8:30 PM, Ralph Goers ralph.go...@dslextreme.com wrote:

 On Dec 29, 2009, at 6:22 PM, Paul Benedict wrote:

 I think Maven POMs should be like the rules governing HTML and CSS
 versions. Ignore tags and attributes you don't know and interpret what
 you can. Allow graceful degration of behavior so those who want to
 publish 4.1 POMs can still be used with 4.0 readers.

 Graceful degradation doesn't work. 4.0 is strict. Maven 2.x won't handle 
 anything undefined. The only reasonable solution is that the new project 
 descriptor won't be a pom.xml.  pom.xml will always be reserved for a 2.x 
 compatible POM.

Unless Maven 2 is given the ability *today* to be forward compatible,
I agree, then it has no chance of being graceful. What a pity. I
believe forward-compatibility would be a great thing and the 20(?)
years of HTML specs would be valuable to learn from.

Paul

-
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?