Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of flamefew@gmail.com designates
 64.233.166.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=F2CtjQfknTsyBzclGasTGg+t9xffBB1BRheKv/moe05TW1SUyE/8cOOn8Nw9fpd5jloZHpW0WlOZonju9oy6uKCpOdkfxnplemmvFX3PYNjfkTbassELsSf/9xNbqwlkCPR9c1tEEKJTn+3R0dohnNsijLTfTe+59FmxWNsixUo=
Message-ID: <31cc37360605181230s84427c6j21018bba781c0572@mail.gmail.com>
Date: Thu, 18 May 2006 12:30:52 -0700
From: "Henri Yandell" <flamefew@gmail.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
In-Reply-To: <1a5b6c410605181219t3ddb63dcoa5873c5eb32c42a8@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <44337A3B.3010902@capgemini.fr>
	 <adba96190604051626t30982914m9c446190a8effac8@mail.gmail.com>
	 <16d6c6200604051637w5642e178qf5043d4a0309d3ff@mail.gmail.com>
	 <4434BA8B.7010200@capgemini.fr>
	 <1147518485.8876.4.camel@knossos.elmet>
	 <31cc37360605171727j1c89f25ayc87d42ac1e07892a@mail.gmail.com>
	 <446CC082.2090108@apache.org>
	 <31cc37360605181157x5de37c2dp9d03ee4af27adf62@mail.gmail.com>
	 <8a81b4af0605181210v2eaa7a11haecdd2f262bb4724@mail.gmail.com>
	 <1a5b6c410605181219t3ddb63dcoa5873c5eb32c42a8@mail.gmail.com>

It's also good for providing a standard way of doing things.

Our .zip files are terribly unstandard. We have source in /src/
/src/java /src/share and /src/main (at least), and javadoc in /api
/apidocs /api/docs and others.

I was under the understanding that regardless of maven usage, the src
and javadoc jars were more useful for users of the IDEs. That the IDE
could point at those jars when it can't point at the zips.

Hen

On 5/18/06, Carlos Sanchez <carlos@apache.org> wrote:
> 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 =
(=3Done
> > > > artifact) per subproject, I believe that org.apache.commons will wo=
rk
> > > > 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. Als=
o
> > > > > 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 i=
nto
> > > > 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org