> From: Nick Chalko [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 4 December 2003 6:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: subproject URI naming convention
> Tim Anderson wrote:
> >3. Change <product-specifier> so that it is opaque
> > repository-uri = access-specifier "/" product-specifier "/"
> > version-specifier "/" artifact-specifier
> > product-specifier = path_segments
> > . recommend that <product-specifier> contains:
> > . reverse FQDN
> > . project name
> > . subproject name(s)
> > . can scale to arbitrary levels of subprojects
> > . tools must parse URIs right to left, in order
> > to separate version-specifier and product-specifier
> > . tools must derive organisation, project, and subproject information
> > from meta-data
> > E.g:
> > http://repo.apache.org/org/apache/jakarta/commons/lang
> > http://repo.apache.org/org/apache/xml/batik
> >I'm beginning to prefer option 3.
> What is the minimum amount of Meta Data we can use to support this.
> I can see this as just arbitrary super-projects and a project is a dir
> that has a dist directory.. or something.
> But really what is an organization. what is a project what is a
The above doesn't try to make the distinction. It merely
aims to organise the repository to better reflect project
In doing so, it avoids the need to come up with naming
schemes like "represent subprojects by using the top level
domain name for <organisation>, and concatentate project and
subproject names together to get <project>".
As for meta-data - I see that as outside the scope at the moment,
as tools can still:
. construct URIs to unambigously locate an artifact.
. parse URIs to extract project, version and artifact information.
> In the end a "leaf" project is something that has distrabutables, like
> jar's or zip's for source files.
> Everything before that is just an arbitrary amount of grouping of projects
> So really it comes down to how many levels of groups to we want 1
> or 2 or n.
> The fact that commons-lang and commons-io are both part of the same
> Jakarta Project has no meaning to a repository.
True, but users browsing the repository can find them easier if
they are grouped together.
> Because of that I still support having a specific number of non
> optional project grouping levels.
> I feel grouping at the organization level is enough. but I am not
> against a mandatory second level but I would call it