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="ge">3.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: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
