commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Date Wed, 09 Mar 2011 06:56:05 GMT
Hi Sebb,

sebb wrote:

> On 9 March 2011 02:46, Gary Gregory <> wrote:


>> Ug, I cannot change the groupId because I cannot change the package.
>> Codec 1.5 fixes some long standing bugs introduced in 1.4.
>> If I change the groupId... Are we talking end of the Maven world or
>> wasted memory?
> Neither.
>> I do not understand enough about the Maven guts to grok the
>> consequences...
> Maven uses the groupId:artifactId tuple to decide if two components
> are the same.
> So if VFS depends on c-logging:1 and NET:2 and NET:2 uses
> c-logging:2.1 Maven will add only logging:2.1 to the classpath.
> But if c-logging:2.1 has a different groupId - e.g. o.a.c-logging -
> from c-logging:1, both will end up on the classpath. Not good.
> Now there is a relocation POM which is supposed to tell Maven that
> c-logging is the same as o.a.c-logging.
> However, the relocation is stored only under original groupId, and
> AFAIK only on the latest version.

No, you can (and should) add a relocation pom for all new versions.

> For the relocation to work, Maven would have to read all the poms.
> In the example above, it would have to start with c-logging:1, and
> find the relocation pom in (say) c-logging:1.13.

It does not! It's no proactive task. They are only considered if someone 
uses the new version with the old groupId, then - and only then - will Maven 
recognize that it looks for the same artifact. Say, you can setup a 
dependencyManagement section in your POM and use the new version for the old 
and new G:A:V scalar, then this works as expected. But it means that a 
relocation for the new version must exist.

> I tried to find out if Maven does this, but noone on the Maven list
> could say for sure.

No wonder, because its limitation is serious and the feature is more or less 
unused now.

> I suspect not, because local workspaces don't have poms apart from the
> ones that have been directly referenced.

Correct assumption.

> The info needs to be in the local workspace otherwise offline mode won't
> work.

No, you have Maven to point to a version that has a relocation like in the 
scenario above with the depMgmt section.

> I have not found time to test how /if it works. I think this will
> require a released component with a relocation pom, plus several dummy
> projects that use versions either side of the relocation. Then a test
> to show the classpath. Then delete the local copy of the relocation
> pom and see if Maven finds it.
> The same considerations apply to changing the artifactId.

It's not worth the time, simply avoid it and Gary should keep the old 
groupId unless we break the API in a way we need a different package name.

- Jörg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message