commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: m2 groupIds
Date Wed, 14 Feb 2007 07:31:53 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message