To summarise, there are three possible ways to encode
subprojects in URIs:
1. Status quo
repository-uri = access-specifier "/" product-specifier "/"
version-specifier "/" artifact-specifier
product-specifier = organisation "/" project
. recommend that <organisation> is the reverse FQDN
. for subprojects, <project> is the concatenation of project and
subproject
names
. tools can't determine project and suproject names from URI
E.g:
http://repo.apache.org/jakarta.apache.org/commons-lang
2. Introduce mandatory <subproject> path
i.e, change product-specifier:
product-specifier = organisation "/" project "/" subproject
. recommend that <organisation> is the reverse FQDN
. no need to concatenate project and subproject names
. doesn't support subprojects nesting > 1
. redundant directory for projects with no subprojects
. tools can determine project and suproject names from URI
E.g:
http://repo.apache.org/org.apache.jakarta/commons/lang
http://repo.apache.org/org.apache.xml/batik/batik
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.
-Tim
