On 25 August 2010 01:00, Niall Pemberton <niall.pember...@gmail.com> wrote: > On Tue, Aug 24, 2010 at 7:37 PM, sebb <seb...@gmail.com> wrote: >> On 24 August 2010 19:17, EJ Ciramella <ecirame...@casenetinc.com> wrote: >>> No, we didn't realize the relocation poms existed until it was too late. >>> >>> We wanted to match up in source control/java package/groupId/artifactId so >>> that they were uniform. Which is great because from just about any angle >>> (stacktrace, source path, package name in IDE) you know exactly where to >>> look elsewhere to find something (say, you wanna look at local disk or >>> source browser, etc). >>> >>> The main problem was communication. There was a lot of hate mail as older >>> modules that hadn't been touched in a long time were dredged up for >>> something or another and when people tried to point at newer version of the >>> relocated libraries, things were missing, etc. >>> >>> There were maybe, 50 or more versions for any of the moved modules floating >>> around that all would need these silly "relocation" poms to support older >>> builds. >> >> What do you mean here? >> Are you saying that if the groupId is changed for a new release, one >> also needs to change all existing releases to add relocation poms? >> I thought one only had to add the relocation POMs for the new releases? >> >>> Everything is possible given an endless amount of time/energy/etc. We >>>wound up having to branch things just to update groupIds, blah blah blah - >>>it was a mess. >>> >>> This is a massive generalization. >>> >>> Keep it stupid simple, right? Don't move things around... >> >> I'm not proposing moving anything around; just changing the groupId >> going forward. >> >> Is that likely to cause any problems? > > Yes - the problem is going to be users getting more than one copy of > an artefact on their classpath. its been discussed a few times on the > Commons dev list - I found the following thread. > > http://markmail.org/message/tky6c734r2dia2gd > > AIUI relocation can't really help with this
I think I see now. If a project uses the old groupId to download the release with the new groupId then it will find the relocation POM, and Maven can potentially correlate the old and new groupIds. However if the project uses the new groupId, the relocation POM will not necessarily be read. Seems to me that this is a problem that Maven should solve, e.g. by providing reverse relocation information in the poms which have the new groupId. That would then allow Maven to correlate the old and new Ids, regardless of which groupId was used to reference the artifacts. The other issue here is that the documentation does not point out these problems, indeed appears to suggest that relocation POMs will solve the problem. It should also be made very clear that choosing the groupId (etc.) needs to be done very carefully, as it is difficult to change later --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
