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 20:09:34 GMT
On Thu, 2005-07-28 at 20:22 +0100, Steve Loughran wrote:
> On 7/28/05, robert burrell donkin <rdonkin@apache.org> wrote:

<snip>

> > 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.
> 
> yes, org.castor makes the most sense. 

virtual organisation does make sense: the first two parts of the
package. 
 
> > > 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
> 
> unless they have their own domain/org. Certainly projects I work on by
> day are sforge hosted, but they have their own domains. even my laptop
> has its own domain these days.

yep. i suppose that the real point is exactly what the organisation
means.

i think that the first two parts of the package name would work nicely
for the virtual organisation (java organisational uri, perhaps?), a lot
better than the actual organisation that happens to be hosting the
project at this particular time.
 
> > > 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?
> 
> I worry about apache itself devolving to a flat directory structure
> too. I suppose the main projects could be standalone, but what about
> the commons things?

who knows the future? some say they'll end as the whole of jakarta. some
say they'll end as a TLP. maybe everyone will just move to pastures new.

one complexity is that there is a certain amount of reshuffling of
component between the various TLP's. i think that this may increase in
the future. (lots of other TLPs are creating their own commons and
existing components may elect to jump ship.)  

> > > 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...
> > 
> 
> because flat naming schemes dont scale. http://ibiblio.org/maven/ is a
> case in point.

i agree that a hierarchy is needed but wonder whether a hierarchy of
organisations needs a little more thought. pure package name probably
can't be used (for example, jaxme distributes a clean room JAXB api
which is packaged javax but is created by apache) but nether can hosting
organisation. i think that virtual organisations (usually the start of
the java package name) would work a lot better than hosting
domain/organisation. 

i also suspect that general rules would work better in the medium term
than jakarta specific ones. this would allow other TLPs to fit more
easily into the framework...

- robert 

Mime
View raw message