Hi Geoffry,
Geoffrey De Smet wrote:
> I agree that a global relocations.xml would not scale.
> You can't change the old (5.1.0) pom,
> so the most obvious place is simply adding this meta-data in the new pom
> (5.2.0):
>
> <groupId>org.drools.guvnor</groupId>
> <artifactId>guvnor-repository</artifactId>
> <version>5.2.0</version>
>
> <legacy-identifications>
> <legacy-identification>
> <groupId>org.drools</groupId>
> <artifactId>drools-repository</artifactId>
> <legacy-identification>
> </legacy-identifications>
>
> Then maven knows that guvnor-repository conflicts with drools-repository.
>
> Exclusions are a mess, in my opinion they are evil (even though I use
> them myself).
> Here's why: you add an exclusion today (after getting hurt because you
> didn't)
> - because of dependency bar forget to declare X as optional
> - because you don't want the transitive dependency drools-repository,
> because you got the newer guvnor-repository
> but tomorrow, when you upgrade to the next version of bar,
> you don't touch the exclusions because if you remove one and the build
> succeeds, it might still be luck (because the classpath order puts
> guvnor-repository 5.2.0 first on your machine).
> So you leave the exclusions in there... even though they might not be
> needed any more.
>
> A couple of years down the line and you get a build pom.xml like ours :)
Actually I'd like to have a replacements section in the depMgmt to define
something like:
<depMgmt>
<replacements>
<replacement>
<replace>
<groupId>org.ow2.spec.ee</groupId>
<artifactId>ow2-atinject-1.0-spec</artifactId>
<!-- possible classifier -->
</replace>
<with>
<groupId>javax.inject</groupId>
<artifactId>javax.inject</artifactId>
<!-- possible classifier -->
</with>
</replacement>
<replacement>
<replace>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
</replace>
<with /> <!-- part of JDK now -->
</replacement>
</replacements>
</depMgmt>
Like the dependency definitions, the replacements would also be applied for
transitive deps. Especially for someone developing with JSF this would be a
life saver looking at the dependency mess in this area.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
