Hi Dennis, Dennis Lundberg wrote on Wednesday, February 07, 2007 9:39 PM:
[snip] >>> I put together this document when I was trying to pull through the >>> whole groupId change last time: >>> >>> http://maven.apache.org/guides/mini/guide-relocation.html >>> >>> There is never a good time to change the groupId. My view is that we >>> should do it when we move to M2, both as a build tool and as the >>> target repository. >> >> Yes, I tried to use this description for a M1 -> M2 situation. In >> the end Carlos' advice was to ignore all the old versions and simply >> start with the new M2 releases also to use the new groupId and add >> for those releases only a relocation POM. > > That is a much easier way to do it. I'm starting to think > that this is > the way to go for Commons. Just change the groupId when we release > with M2 and don't relocate older versions. Yep. If we agree all on this, we can immediately start to use the new groupId. It's just, that the release & deploy process will not automatically create those relocation POMs. >> The problem with adjusting the old releases is, that the >> location for the relocation POMs is already occupied by the >> automatically generated POMs for M2 on the global M2 repo (see >> > http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/ > commons-logging/1.1/). >> And since they're already published, they cannot be changed anymore. > > I think you are allowed to add a relocation section to an already > published pom. I vaguely remember discussing this with Carlos back > then. Well, it seems, they become more strict since then. I got definitely a negative answer from him as to replace the old POMs from ibiblio with the ones including the relocation section available on a synchronized site. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
