I've been lurking for a little while now, and appreciate all the work you
guys have done working on this spec.
I agree with both Tim and Stephen in regards to below. I believe that there
should be a *mandatory* subproject descriptor because it allows for more
flexibility with regards to project management. Take for example the
* There are different versions of a specific project, not just evolutions
but different packages, something like a commercial product that has a
"basic", "premium", and "ultra" configuration (assuming that this repository
specification could work for commercial products). With subproject
designations, the configuration could be specified because the "ultra"
configuration contains many more features than the "basic" configuration.
* The Jakarta Commons project - enough said there, along with similar
situations like the Apache Incubator and other projects.
* A standalone project - the "accepted" project (like the HEAD branch)
could be called the subproject "main" (or something like that), but there
could be other variations (take the Linux Kernel, for example - there are
versions that are not included in the main source tree, like grsecurity, but
still create a Linux kernel - and can be distributed), that would value from
Along with Stephen, I believe that organizations should not be in the URI,
My $0.03 (it's a little more than $0.02 :)),
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 30, 2003 11:26 PM
To: [EMAIL PROTECTED]
Subject: Re: subproject URI naming convention
Tim Anderson wrote:
>The URI proposal  doesn't provide explicit support
>for subprojects - the assumption being that these will
>be encoded in the product-specifier portion of the URI:
> repository-uri = access-specifier "/" product-specifier "/"
> version-specifier "/" artifact-specifier
> product-specifier = organisation "/" project
>Using jakarta commons as an example, there are a several possible
> A. http://repo.apache.org/apache/commons-cli
> B. http://repo.apache.org/jakarta.apache.org/commons-cli
> C. as in [B], but with "org.apache.jakarta" for organisation
> D. http://repo.apache.org/jarkarta.apache.org-commons/cli
> E. as in [D], but with "org.apache.jakarta-commons" for organisation
> F. http://repo.apache.org/jarkarta-commons/cli
> G. http://repo.apache.org/apache-jarkarta-commons/cli
>Of the above, [F] best matches CVS organisation:
>Which is the preferred approach?
>Another possibility is to add a mandatory subproject path segment:
> product-specifier = organisation "/" project "/" subproject
>(mandatory so the URI can be parsed), giving:
> H. http://repo.apache.org/jakarta.apache.org/commons/cli
> I. as in [H], but with "org.apache.jakarta" for organisation
>This would mean a redundant directory for those projects
>with no subprojects, e.g:
>. better reflect project heirarchies
>. improve navigability, as the heirarchy is not as flat
>. avoid the need to specify naming conventions for subprojects:
> . organisation is always derived from the project domain name
> . project is always the top level project name
> . subproject is the subproject name, or in the absence of
> a subproject, the same as the top level project name.
This has been quietly bugging me for the last week - but I havn't had
the time to make a constructive suggestion.
However - for what it worth - I think it would be better to collapse
[organization]/[project] in a simple [path] statement. The upside of
this is that you have a lot more scalability with respect to nested
subprojects, etc. The downside is identification of the organization
from the URL. From my own experience I never deal with organization
info at the url level. That's the sort of thing I'll pull out of
metadata bound to an artifact (e.g. jar manifest, block description,
This would suggest :
(replacing the organization/project spec)
But I'm wondering if this will break things downstream?
Stephen J. McConnell
| Magic by Merlin |
| Production by Avalon |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |