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:



 C. as in [B], but with "org.apache.jakarta" for organisation


 E. as in [D], but with "org.apache.jakarta-commons" for organisation



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:


 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:
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.




Reply via email to