you can change the old poms to relocate to a new location as long as
the new location has the same old jars and poms (just groupId change).
IIRC your case was different.
So, I' see two options for relocation:
1) when new version is out with new groupId add relocation pom in old
location just for that new version.
+ Users updating version in old location will get a warning
+ easy to do
- users may end having old versions and new versions in the
classpath, that they would have to solve with exclusions
2) relocate all versions to new groupId
+ all users will only notice the warnings when using old group
+ no classpath problems in builds from scratch
- harder to implement, will need to write some code
- people with commons artifacts cached (almost everybody) will
experience same problems as in 1, possibly getting two versions in the
classpath
I'd stick with 1) changing old releases scares me ;) and still doesn't
guarantee trouble free upgrades
On 2/13/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
you cannot change the old POMs anymore, in that case this description is
obsolete. The only valid option is to use the new groupId with a new release
and provide for this new release a relocation POM at the former location. This
was Carlos' advice after a two week hassle to do such a transition with XStream.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
