right a relocate pom for ALL versions is required to avoid duplication
on classpath
BUT as I said almost everybody will have cached previous versions of
commons so they won't see the relocation until they delete local repo
and the poms with relocation info get downloaded.
On 2/13/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
What in such a scenario :
My project depends commons-xxx-1.2, relocated at org.apache.commons.xxx-1.2
My pom get transitive commons-xxx-1.1
If I DON't update my POM maven2 will find the relocated artifact and exclude
1.1 - that's fine
If 1.1 has no relocated POM, and if I update my POM, maven2 will get both
1.1 and 1.2 as they will not be detected as same artifact
This mean a relocated POM for all oldest release is required to avoid
duplicated jars in classpath.
(am I wrong ?)
2007/2/13, Carlos Sanchez <[EMAIL PROTECTED]>:
>
> scenario 3 is with no relocation pom at all, so users get involved by
> having to explicitly change the groupId
>
> On 2/13/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
> > I don't understand the distinction you make between scenario 1 and 3 :
> >
> > if new release use a relocation pom under commons-xxx and DOESN'T deploy
> a
> > jar under this group
> > - maven2 users will get relocated artifact + a warning to update
> > dependencies
> > - maven1 users will not get the new version, may ask for it or only
> found
> > the POM and will update dependencies
> >
> > am I wrong ?
> >
> > Nico.
> >
> >
> >
> > 2007/2/13, Carlos Sanchez <[EMAIL PROTECTED]>:
> > >
> > > oh there's a 3rd option that I even like more
> > >
> > > 3) make new releases in new groupid, no relocations at all
> > > + easiest ;)
> > > + users trying to upgrade will need to know that the groupId has
> > > changed and act by themselves, so they will be involved, and in case
> > > of classpath problems they will know what has changed
> > > - it'd be better to wait until a major/minor release so users can get
> > > bugfixes easily
> > >
> > >
> > > On 2/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> > > > 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
> > > >
> > >
> > >
> > > --
> > > 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]
> > >
> > >
> >
>
>
> --
> 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]
>
>
--
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]
