The URI proposal [1] 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
naming conventions:
A. http://repo.apache.org/apache/commons-cli
http://repo.apache.org/apache/commons-collections
http://repo.apache.org/apache/commons-logging
B. http://repo.apache.org/jakarta.apache.org/commons-cli
http://repo.apache.org/jakarta.apache.org/commons-collections
http://repo.apache.org/jakarta.apache.org/commons-logging
C. as in [B], but with "org.apache.jakarta" for organisation
D. http://repo.apache.org/jarkarta.apache.org-commons/cli
http://repo.apache.org/jarkarta.apache.org-commons/collections
http://repo.apache.org/jarkarta.apache.org-commons/logging
E. as in [D], but with "org.apache.jakarta-commons" for organisation
F. http://repo.apache.org/jarkarta-commons/cli
http://repo.apache.org/jarkarta-commons/collections
http://repo.apache.org/jarkarta-commons/logging
G. http://repo.apache.org/apache-jarkarta-commons/cli
http://repo.apache.org/apache-jarkarta-commons/collections
http://repo.apache.org/apache-jarkarta-commons/logging
Of the above, [F] best matches CVS organisation:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/
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
http://repo.apache.org/jakarta.apache.org/commons/collections
http://repo.apache.org/jakarta.apache.org/commons/logging
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:
http://repo.apache.org/xml.apache.org/batik/batik
but would:
. 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.
Thoughts?
-Tim
[1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax
