www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <rdon...@apache.org>
Subject Re: Maven repository policies
Date Thu, 28 Jul 2005 17:45:18 GMT
On Thu, 2005-07-28 at 10:22 +0100, Steve Loughran wrote: 
> On 7/27/05, robert burrell donkin <rdonkin@apache.org> wrote:
> > On Tue, 2005-07-26 at 07:12 -0700, Phil Steitz wrote:
> > > Brett Porter wrote:
> 
> > this is a good point: organisations change but code continues.
> > 
> > why not just use package names?
> > 
> 
> because often package names themselves are historical accidents.
> "org.apache.tools.ant", being a case in point, how microsoft used
> com.ms for all their J++ stuff another (that is morgan stanley's
> domain, see)

the organisation structures associated with open source projects are
also often historical accidents. at least the package is something which
is code related and embedded in the artifacts. 

for example, it's asking a lot for a user to know that for castor x.y.z,
i need to look under www.exolab, for castor a.b.c i need to look under
sourceforge.net and for castor n.m.l i should look under java.net. IMHO
not obvious. on the other hand, org.castor is really easy to find.

> maybe it could be like package naming, with some rules but also
> per-org freedom. Here, using the MUST/MAY/SHOULD terminology of IETF
> specs:
> 
> 0. packages MUST use the domain at the beginning (org.apache,com.sun)

therefore projects hosted at sourceforge would have to start with
sourceforge.net

> 1. it's left to every organisation to do layout under there -we just
> declare what they SHOULD do.
> 
> 2. for apache, jakarta stuff MAY go toplevel, as would tomcat, ant,
> maven, xml, ws projects.

is there any particular reason why you have proposed jakarta as a
special case?

> 3. jakarta-commons MUST  be separate from org.apache.commons, 

is there any particular reason why you have proposed jakarta-commons as
a special case?

> in case there is an xml-commons, ws-commons, etc.

(FWIW these already exist but coexist by choosing different names for
components)

maybe i'm missing the reason why organisation structure needs to be
embedded in the structure of the repository...

- robert

Mime
View raw message