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]
