commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nicolas de loof" <nicolas.del...@gmail.com>
Subject Re: m2 groupIds
Date Wed, 14 Feb 2007 06:50:49 GMT
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 <carlos@apache.org>:
>
> 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 <nicolas.deloof@gmail.com> 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 <carlos@apache.org>:
> > >
> > > 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 <carlos@apache.org> 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 <Joerg.Schaible@elsag-solutions.com>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message