On 2/13/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
According to this, when relocation projectX for new release N+1
option 1 : making dependency to oldGroupId:N+1 will work, but making
dependency to newGroupId:N+1 will introduce duplicate jars issues if other
dependencies introduce transitive-dependency to oldGroupId:N
iirc "making dependency to oldGroupId:N+1" won't work because maven
internally transforms it to newGroupId:N+1, so no difference
option 2 : relocating all POM will fail du to proxies caching / mirror /
sync issues and others, so will get duplicate jars issues
option 3 : same as 1
All options introduce duplicate jars issues.
yes, so 3 would involve the user and when something breaks it won't be
"magically"
The only solution I can find should be to have some meta-data in the POM to
refer the old groupId, so that maven nows that newGroupId:x is the same
artifact as oldGroupId:x
Already in jira, no progress yet
http://jira.codehaus.org/browse/MNG-2316
2007/2/14, Jörg Schaible <[EMAIL PROTECTED]>:
>
> 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]
>
>
--
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]
