commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: [all] maven group ids
Date Sun, 20 Aug 2006 00:11:01 GMT
On 8/19/06, Oliver Heger <oliver.heger@oliver-heger.de> wrote:
>
> Tomasz Pik wrote:
> > On 8/16/06, Dennis Lundberg <dennisl@apache.org> wrote:
> >
> >> > Yes, but instead of transiting something, that depends on other
> commons
> >> > IMHO something without dependencies should be transited first.
> >> > In other words, first thing to be done should be a graph of
> >> dependencies
> >> > between various commons packages and those without dependencies
> >> > should be migrated first. I guess commons-lang is a good candidate
> >> here,
> >> > not configuration that depdends on many other (not migrated yet)
> >> > components.
> >>
> >> What would we gain from this? A transition of component A will not
> >> include updating existing commons-dependencies in component A to the
> new
> >> ones with the new groupId. That will require a new release of that
> >> component A. If fact we don't even have to wait for a release of a
> >> component to do this.
> >>
> >> There is a good reason for *not* picking commons-lang or
> >> commons-logging, two components without dependencies on other commons
> >> components, as the first component to transition. That is that both are
> >> on ibiblio's top 10 downloads list. I had link to it before but can't
> >> seem to find it now, sorry. If we do it wrong there then all hell will
> >> break loose. It'd be better to choose a "medium used" component.
> >
> > But this means, that all of those users, that downloading those top10
> > jars in near future will have obosolete jars.
> > Maven is not re-downloading nonSNAPSHOT artifacts so...
> > Let's imagine I'm a new maven user having project with a dependency on
> > commons-lang:commons-lang-2.1 and maven will download it for me.
> > Some time later this package will be relocated to
> > org.apache.commons.lang:commons-lang:2.1 (or similar).
> > After that there'll be new, let's say acegi v1.4 depending on this 'new'
> > commons-lang (org.apache....:commons-lang:2.1) and I need this acegi
> > in my project.
> > So after adding dependency on acegi maven will download
> > org.apache.commons.lang:commons-lang:2.1 and won't download
> > commons-lang:commons-lang:2.1 (which should result as relocation
> > info) and finally, maven will be adding those two commons-lang jars
> > into classpath, copy into WEB-INF/lib and so on.
> > All of this till the time I'll manually remove
> > commons-lang:commons-lang:2.1
> > from my repository so maven will be forced to reload them (and will
> > download relocation info then).
> > So finally I think that sooner those jars will be relocated there'll be
> > less
> > users having problems like this.
> >
> > Regards,
> > Tomek
> >
> > --
> >> Dennis Lundberg
> >
>
> There are good reasons in this thread from both sides. Being no maven
> expert I cannot judge which ones are better.
>
> But as long as this point is open I don't want to cut the next release
> candidate for [configuration]. So can we come to a consensus?


FWIW, I am planning to provide both .asc and .sha1 signing keys on the
upcoming Shale release I'm working on.  The .md5 files aren't really a
signature ... they're just a checksum useful in determining whether the
download has been corrupted or not (it is based solely on the content, not
on any private key of the signer).


Oliver


Craig


---------------------------------------------------------------------
> 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