subproject URI naming convention
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
Re: subproject URI naming convention
Tim Anderson wrote: 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? 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, whatever). This would suggest : http://repo.apache.org/org/apache/jakarta/commons/cli/ | | |<--->| | product specifier (replacing the organization/project spec) But I'm wondering if this will break things downstream? Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | ||
RE: subproject URI naming convention
Hi all, 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 following situations: * 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 being subprojects. Along with Stephen, I believe that organizations should not be in the URI, just because. My $0.03 (it's a little more than $0.02 :)), -Matt Kurjanowicz -Original Message- 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 [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? > 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, whatever). This would suggest : http://repo.apache.org/org/apache/jakarta/commons/cli/
Re: subproject URI naming convention
This is what I would recommend. Each top level Apache project is an Orginzation. Organitations are the reverse FQDN (so they sort) Sub projects inside of a orginzation are seperated with - so that we have http://repo.apache.org/jakarta.apache.org/commons-lang R, Nick
Re: subproject URI naming convention
Nick Chalko wrote: This is what I would recommend. Each top level Apache project is an Orginzation. Organitations are the reverse FQDN (so they sort) Sub projects inside of a orginzation are seperated with - so that we have http://repo.apache.org/jakarta.apache.org/commons-lang oOOPS. http://repo.apache.org/org.apache.jakarta/commons-lang Ahh there it is REVERSE FQDN :-[ R, Nick
Re: subproject URI naming convention
Understanding that we are at the detail level and any of this will work. The two questions up are org/proj and allowing and/or forcing org/proj/sub-proj. I have made the case in the past for not allowing arbitrary "/" in part names because it makes the URI hard to parse. Not hard to generate but hard to parse. For the same reason I also discourage optional dir's For example what is the org project subproject of this http://repo.apahce.org/alpha/beta/alpha/beta/alpha/beta/alpha/jars/alpha-beta.jar That said I am fine with manditory sub-projects. but I think we are fine without them using just "-". egcommons-lang and commons-log On the Orginzation part. It does seem redundant to say http://repo.apache.org/apache/ I anticipated the org part for mirrors so we would have something like http://repo.mirror.com/apache and http://repo.mirror.com/sun But we can do that anyway. It is really just a sematic thing, ie are the two URL's above part of one Apache style repository or are the two seperate repositories. I prefer to think of them as one repository. R, Nick
