Hi Carlos,

Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM:

> 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 don't know whether I should laugh or cry because you "offered" option 2 at 
all. I took option 2 and adjusted all the old releases of XStream on the 
Codehaus repo, but they do not get synced to the public repo, since the space 
for the relocation POMs is already occupied by the old files. It was you who 
said, nothing can be done about this. Why should the synchronization of the 
Apache repo be different to the one of Codehaus?

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to