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. 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... -----Original Message----- From: sebb [mailto:[email protected]] Sent: Tuesday, August 24, 2010 2:08 PM To: Maven Users List Subject: Re: Correcting a groupID On 24 August 2010 18:44, EJ Ciramella <[email protected]> wrote: > Yeah, I know - hate to cross-pollinate here but the Nexus bible states the > repo is for deposits only. > > Essentially backing up the "just change NEW snapshots/releases, leave the old > ones where they are" sentiment. OK > In another life, I casually agreed we should change the groupId of an > artifact and all hell broke loose... Did you use relocation POMs? What were the exact problems? Could they have been avoided, and if so, how? > > > -----Original Message----- > From: Wayne Fay [mailto:[email protected]] > Sent: Tuesday, August 24, 2010 11:00 AM > To: Maven Users List > Subject: Re: Correcting a groupID > >> The guide to relocation: >> >> http://maven.apache.org/guides/mini/guide-relocation.html > > Hmmmmmmm I really don't agree with this approach, and don't believe it > would pass muster today. This documentation is most likely old. > > Today's mantra is "artifacts don't change". This includes poms and > jars etc. I believe the correct approach today would be to put > relocation poms in the old groupId for the new artifact for any new > artifacts for a few releases, while putting the artifacts themselves > in the new groupId, and then stop putting the relocation poms in > completely after some period of time. > > Wayne > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within > including any attachments is only for the recipient(s) to which it is > intended and may contain confidential and/or privileged material. Any review, > retransmission, dissemination or other use of; or taking of any action in > reliance upon this information by persons or entities other than the intended > recipient is prohibited. If you received this in error, please send the > e-mail back by replying to the sender and permanently delete the entire > message and its attachments from all computers and network systems involved > in its receipt. > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within including any attachments is only for the recipient(s) to which it is intended and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of; or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please send the e-mail back by replying to the sender and permanently delete the entire message and its attachments from all computers and network systems involved in its receipt. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
