commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlos Sanchez" <car...@apache.org>
Subject Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Date Thu, 18 May 2006 19:19:09 GMT
Sources and javadocs are great for maven users because when maven
generates the IDE projects it will check the repo for them, download
and link inside the IDE, enabling debugging through third party
sources or reading the javadocs while coding.

On 5/18/06, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 5/18/06, Henri Yandell <flamefew@gmail.com> wrote:
> > On 5/18/06, Dennis Lundberg <dennisl@apache.org> wrote:
> > > Henri Yandell wrote:
> > > > On 5/13/06, robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
> > > > wrote:
> > > >> On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote:
> > > >> > I agree about NOT making non-final jars available on ibiblio
> > > >> (httpclient
> > > >> > beeing an exception)
> > > >> > So could the next RC be uploaded to
> > > >> > http://cvs.apache.org/maven-snapshot-repository/ ?
> > > >> >
> > > >> > Please also consider using the new groupId recommandation for
apache
> > > >> > commons-X : org.apache.commons.X
> > > >>
> > > >> should we make this change for the whole of the commons?
> > > >
> > > > Opening this up again.
> > > >
> > > > groupId: org.apache.commons
> > > > or
> > > > groupId: org.apache.commons.X
> > > >
> > > > ??
> > >
> > > As one of the goals in the commons charter (12) is to have one jar (=one
> > > artifact) per subproject, I believe that org.apache.commons will work
> > > nicely.
> > >
> > > > The M2 repository has a better hierarchical structure, so I'm not sure
> > > > we have to worry about jamming X in place.
> > > >
> > > > Here's the m2 repo for my commons-alike testing project:
> > > >
> > > > http://www.ibiblio.org/maven2/genjava/
> > > >
> > > > I'm thinking a group id of org.apache.commons for each component would
> > > > work well.
> > > >
> > > > We've got both logging and collections in need of deployment. Also
> > > > need to start putting the javadoc and sources in there too if
> > > > possible.
> > >
> > > What would be the best way to do this? Should we try to cram this into
> > > the Apache Maven 1 repo or should we start to provide Maven 2 POMs for
> > > all commons components instead? The Maven 2 repo has better support for
> > > these kinds of extras.
> >
> > Maven 1 repo; until we start doing it automatically from an m2 build
> > system. Less chance of us messing up the m2 repo that way.
> >
> > I'm working on deploying a lot of the javadoc.jars for commons
> > versions; then will do sources.
>
> Out of curiousity, why exactly do we want to duplicate the
> distribution of these things?  What exactly does it buy us or our
> users?  What is so hard / onerous about just downloading the official
> distros?  I understand (and depend on) the practical value of the
> maven repo for binary jars,  but don't see the compelling reason to
> duplicate src and javadoc distros.  Until we have good automated
> signing and distribution from tags in place, I think we should avoid
> unnecessary duplication and as much as possible hold onto the
> connection
>
> tag <-> vote <-> distro <-> sig
>
> Breaking things apart and redistributing manually is asking for trouble, IMHO.
>
> Phil
>
> ---------------------------------------------------------------------
> 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
View raw message