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="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: 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
