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]

Reply via email to