Hi Sebb, sebb wrote:
> On 9 March 2011 02:46, Gary Gregory <garydgreg...@gmail.com> wrote: [snip] >> 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
