RE: subproject URI naming convention
See inline. > From: Nick Chalko [mailto:[EMAIL PROTECTED] > > Tim Anderson wrote: > > >Can you provide an example of a URI which can't be parsed? > > > >-Tim > > > >[1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax > > > > > *repository-uri = access-specifier "/" product-specifier "/" > version-specifier "/" artifact-specifier* > > It defines *access-specifier* and *product-specifier*, but leaves > *version-specifier* and *artifact-specifier* opaque, to be defined > by language, platform, or artifact-specific best practices. > > Since version-specifier and artifact-specifier are opaque, there is > no way to tell where product specifier ends. > I know we have suggested version, and a Java artifact specifier. > But what about other languages, Like the "new cool O/S" language foo. > > It's artifact's are called bars > > http://repo.com/org/foo/cat/dog/bars/bar.zip > > What is the product org.foo.cat or org .foo? > Is cat the version name or is dog.? > Perhaps there are two kings of bars, one for dogs and one for eggs. > or what ever. If product-specifier is opaque, and the artifact URI doesn't meet the criteria specified by one or more of the proposals, then a tool can't look at its URI to determine what the product or version is. Does that really matter though? How can a tool sensibly interrogate an artifact it doesn't understand? > > organization/project is a workable solution that lets a tool make > intelligent guesses based on URI only,. > > I like the simplicity of > Top level = Organization that distribute things > 2nd level = A project. (a sub organizational unit that > distributes artifacts) > 3/4 level = Version, (interim builds take an extra level > 4/5 = Artifacts stored any what a project likes. (with best > practices for Java and other languages.) > The ONLY limits we have on organization and project and version is > it must be valid URI character and it can not be a "/" (ie pchar) > I'm not really fussed if product-specifer is opaque or not - I'll go with the concensus view. IMO, the repository layout is cleaner if it is opaque, and tools can still parse any URI which meet the criteria of the proposals. If product-specifier is restricted to 2 path segments, then tools can parse any URI, but the repository structure is flatter, and can't represent project heirarchies. -Tim
Re: subproject URI naming convention
Tim Anderson wrote: Can you provide an example of a URI which can't be parsed? -Tim [1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax *repository-uri = access-specifier "/" product-specifier "/" version-specifier "/" artifact-specifier* It defines *access-specifier* and *product-specifier*, but leaves *version-specifier* and *artifact-specifier* opaque, to be defined by language, platform, or artifact-specific best practices. Since version-specifier and artifact-specifier are opaque, there is no way to tell where product specifier ends. I know we have suggested version, and a Java artifact specifier. But what about other languages, Like the "new cool O/S" language foo. It's artifact's are called bars http://repo.com/org/foo/cat/dog/bars/bar.zip What is the product org.foo.cat or org .foo? Is cat the version name or is dog.? Perhaps there are two kings of bars, one for dogs and one for eggs. or what ever. If we want to leave version specifier and artifact specifier opaque then I think it is important to harden the product specifier. Some limits to version might be acceptable, but artifact should definitely be opaque. organization/project is a workable solution that lets a tool make intelligent guesses based on URI only,. I like the simplicity of Top level = Organization that distribute things 2nd level = A project. (a sub organizational unit that distributes artifacts) 3/4 level = Version, (interim builds take an extra level 4/5 = Artifacts stored any what a project likes. (with best practices for Java and other languages.) The ONLY limits we have on organization and project and version is it must be valid URI character and it can not be a "/" (ie pchar) R, Nick
updated example repository structure (was RE: subproject URI naming convention)
I've updated the example to include versions of commons-jelly, demonstrating the use of snapshots builds. These are located under: org/apache/jakarta/commons/jelly in the archive. It should be easier to navigate and locate snapshot and release builds compared with the flatter structure currently in use by maven (e.g http://www.ibiblio.org/maven/commons-jelly/jars/) Regards, Tim > -Original Message- > From: Tim Anderson [mailto:[EMAIL PROTECTED] > Sent: Saturday, 6 December 2003 4:02 AM > To: [EMAIL PROTECTED] > Subject: RE: subproject URI naming convention > > > Attached is an archive which shows a sample repository structure > where the product-specifier contains >= 2 path segments. > > Hopefully, this will carify things. > > It contains: > . ant versions 1.5.2, 1.5.3-1, 1.5.4 and nightlies of 1.6alpha > . httpd 2.0.48 > . jms 1.1 > . jndi 1.2.1 > . commons-collections 1.0, 2.0 > . commons-cli 1.0, nightlies of 1.0 and 2.0 > . commons-betwixt 1.0-alpha-1, nightlies of 1.0-beta-1-dev > > (all sample files are empty) > repo2.tar.gz Description: Binary data
RE: subproject URI naming convention
Dropping it just for binaries may be fine, but it is nice to have for src and others, since the src and the bin mostly have the same name doesn't seem right. Can be added as an optional one. regards, -Anou From: "Tim Anderson" <[EMAIL PROTECTED]> Reply-To: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: RE: subproject URI naming convention Date: Fri, 5 Dec 2003 09:18:46 +1100 > From: Anou Manavalan [mailto:[EMAIL PROTECTED] > Sent: Friday, 5 December 2003 8:43 AM > > >[1] thinking of dropping "-bin" suffix for binaries. "-src" suffix > > for sources would be retained. > > > > > I would prefer to have the -bin and -src in the artifact name, > reason being > same as why we have the version in there. It looses its URI after > downloading it. True, but I was thinking of dropping it because its not widely used by ASF binary distributions. -Tim _ Wonder if the latest virus has gotten to your computer? Find out. Run the FREE McAfee online computer scan! http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
RE: subproject URI naming convention
Attached is an archive which shows a sample repository structure where the product-specifier contains >= 2 path segments. Hopefully, this will carify things. It contains: . ant versions 1.5.2, 1.5.3-1, 1.5.4 and nightlies of 1.6alpha . httpd 2.0.48 . jms 1.1 . jndi 1.2.1 . commons-collections 1.0, 2.0 . commons-cli 1.0, nightlies of 1.0 and 2.0 . commons-betwixt 1.0-alpha-1, nightlies of 1.0-beta-1-dev (all sample files are empty) -Tim > From: Tim Anderson [mailto:[EMAIL PROTECTED] > > > From: Nick Chalko [mailto:[EMAIL PROTECTED] > > > > Tim Anderson wrote: > > > > > > > >>The fact that commons-lang and commons-io are both part of the same > > >>Jakarta Project has no meaning to a repository. > > >> > > >> > > > > > >True, but users browsing the repository can find them easier if > > >they are grouped together. > > > > > > > > > > > The only difference between > > commons/lang and commons-lang is the number of items in a directory. > > > > but again if we allow arbitrary number of "/" before the the artifact > > part how can we tell what the project is we are back to > > http://repo.com/alpha/beta/alpha/beta/dist/beta-alpha.zip > > http://repo.com/dist/nightly/dist/dist/dist/dist/foo.zip > > > > Silly examples but with out a RIGID spec it will happen. Someone will > > want to name thier project Alpha, or nightly or the orginaztion will > > be named dist or intrim or snapshot. > > > > Lets just pick a number of groupings one or two or three and stick with > > it. > > Allow the "/" to have special meaning. > > > > R, > > Nick > > > > The distinction between organisation and project would no longer exist: > repository-uri = access-specifier "/" product-specifier "/" >version-specifier "/" artifact-specifier > product-specifier = path_segments > > i.e, the organisation, project, subproject etc, are encoded in the URI > using 1-n path segments. > > To ensure that reserved words aren't included in product-specifier, > it would need to be specified as: > product-specifier = path_segments & ~reserved > reserved = formal-build-designation | interim-build-designation > | latest > formal-build-designation = "release" > interim-build-designation = "interim" | "nightly" | "snapshot" | ... > > This means: > . tools cannot parse organisation, project etc details from the URI > . tools can extract product-specifier, version-specifier, and > artifact-specifier by parsing right to left. > repo.tar.gz Description: Binary data
RE: subproject URI naming convention
The Repository URI proposal [1] defines artifact-specifier as: artifact-specifier = path_segments However, this is constrained by the *Artifact Specifier proposals, enabling URIs which follow the proposals to be parsed. For an overview of these proposals, see http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Proposals. Can you provide an example of a URI which can't be parsed? -Tim [1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax > -Original Message- > From: Nick Chalko [mailto:[EMAIL PROTECTED] > Sent: Friday, 5 December 2003 10:32 AM > To: [EMAIL PROTECTED] > Subject: Re: subproject URI naming convention > > > version-name = pchar+ & ~(formal-build-designation | > interim-build-designation | latest) > artifact-specifier = path_segments > With the N levels of grouping you must look FIND the version in the > middle somewhere > but version-name can be jar or apache or jars or foo > and the path_segments in the product and in the artifact-specifier can > also be jar or apache or jars of foo. > > Unless we tighten up version and artifact type we are not going to be > able parse. > > R, > Nick > >
Re: subproject URI naming convention
version-name = pchar+ & ~(formal-build-designation | interim-build-designation | latest) artifact-specifier = path_segments With the N levels of grouping you must look FIND the version in the middle somewhere but version-name can be jar or apache or jars or foo and the path_segments in the product and in the artifact-specifier can also be jar or apache or jars of foo. Unless we tighten up version and artifact type we are not going to be able parse. R, Nick
RE: subproject URI naming convention
> From: Anou Manavalan [mailto:[EMAIL PROTECTED] > Sent: Friday, 5 December 2003 8:43 AM > > >[1] thinking of dropping "-bin" suffix for binaries. "-src" suffix > > for sources would be retained. > > > > > I would prefer to have the -bin and -src in the artifact name, > reason being > same as why we have the version in there. It looses its URI after > downloading it. True, but I was thinking of dropping it because its not widely used by ASF binary distributions. -Tim
RE: subproject URI naming convention
> From: Stephen McConnell [mailto:[EMAIL PROTECTED] > > Tim Anderson wrote: > > >>From: Tim Anderson [mailto:[EMAIL PROTECTED] > >>Sent: Friday, 5 December 2003 8:35 AM > >> > >> > >Damn - forgot version in artifact name... > > > >[snip] > > > >Some examples, using valid URIs: > > > >1. > http://repo.com/alpha/beta/alpha/1.0/binaries/beta-alpha-1.0.zip[1] > >artifact-specifier = "binaries/beta-alpha-1.0.zip" > >version-specifier = "1.0" > >product-specifier = "beta/alpha" > > > > Isn't the product specifier "alpha/beta/alpha" ? > > Steve. > *Sigh* - yes, it should be.
Re: subproject URI naming convention
Tim Anderson wrote: From: Tim Anderson [mailto:[EMAIL PROTECTED] Sent: Friday, 5 December 2003 8:35 AM Damn - forgot version in artifact name... [snip] Some examples, using valid URIs: 1. http://repo.com/alpha/beta/alpha/1.0/binaries/beta-alpha-1.0.zip[1] artifact-specifier = "binaries/beta-alpha-1.0.zip" version-specifier = "1.0" product-specifier = "beta/alpha" Isn't the product specifier "alpha/beta/alpha" ? 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
[1] thinking of dropping "-bin" suffix for binaries. "-src" suffix for sources would be retained. I would prefer to have the -bin and -src in the artifact name, reason being same as why we have the version in there. It looses its URI after downloading it. -Anou _ Shop online for kidsÂ’ toys by age group, price range, and toy category at MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com
RE: subproject URI naming convention
> From: Tim Anderson [mailto:[EMAIL PROTECTED] > Sent: Friday, 5 December 2003 8:35 AM Damn - forgot version in artifact name... [snip] Some examples, using valid URIs: 1. http://repo.com/alpha/beta/alpha/1.0/binaries/beta-alpha-1.0.zip[1] artifact-specifier = "binaries/beta-alpha-1.0.zip" version-specifier = "1.0" product-specifier = "beta/alpha" 2. http://repo.com/dist/dist/dist/dist/nightly/1.0/20031202/binaries/foo-1.0.zi p artifact-specifier = "binaries/foo-1.0.zip" version-specifier = "nightly/1.0/20031202" product-specifier = "dist/dist/dist/dist" -Tim [1] thinking of dropping "-bin" suffix for binaries. "-src" suffix for sources would be retained.
RE: subproject URI naming convention
> From: Nick Chalko [mailto:[EMAIL PROTECTED] > > Tim Anderson wrote: > > > > >>The fact that commons-lang and commons-io are both part of the same > >>Jakarta Project has no meaning to a repository. > >> > >> > > > >True, but users browsing the repository can find them easier if > >they are grouped together. > > > > > > > The only difference between > commons/lang and commons-lang is the number of items in a directory. > > but again if we allow arbitrary number of "/" before the the artifact > part how can we tell what the project is we are back to > http://repo.com/alpha/beta/alpha/beta/dist/beta-alpha.zip > http://repo.com/dist/nightly/dist/dist/dist/dist/foo.zip > > Silly examples but with out a RIGID spec it will happen. Someone will > want to name thier project Alpha, or nightly or the orginaztion will > be named dist or intrim or snapshot. > > Lets just pick a number of groupings one or two or three and stick with > it. > Allow the "/" to have special meaning. > > R, > Nick > The distinction between organisation and project would no longer exist: repository-uri = access-specifier "/" product-specifier "/" version-specifier "/" artifact-specifier product-specifier = path_segments i.e, the organisation, project, subproject etc, are encoded in the URI using 1-n path segments. To ensure that reserved words aren't included in product-specifier, it would need to be specified as: product-specifier = path_segments & ~reserved reserved = formal-build-designation | interim-build-designation | latest formal-build-designation = "release" interim-build-designation = "interim" | "nightly" | "snapshot" | ... This means: . tools cannot parse organisation, project etc details from the URI . tools can extract product-specifier, version-specifier, and artifact-specifier by parsing right to left. Some examples, using valid URIs: 1. http://repo.com/alpha/beta/alpha/1.0/binaries/beta-alpha.zip[1] artifact-specifier = "binaries/beta-alpha.zip" version-specifier = "1.0" product-specifier = "beta/alpha" 2. http://repo.com/dist/dist/dist/dist/nightly/1.0/20031202/binaries/foo.zip artifact-specifier = "binaries/foo.zip" version-specifier = "nightly/1.0/20031202" product-specifier = "dist/dist/dist/dist" Your examples aren't valid: . http://repo.com/alpha/beta/alpha/beta/dist/beta-alpha.zip . "dist/beta-alpha.zip" isn't valid according to [2]-[5] . version-specifier *could* be "beta" according to [6] . product-specifier *could* be "alpha/beta/alpha" . http://repo.com/dist/nightly/dist/dist/dist/dist/foo.zip . "dist/foo.zip" isn't valid according to [2]-[5] . version-specifier *could* be "dist" according to [6] . product-specifier *could* be "dist/nightly/dist/dist", but would be invalid given: product-specifier = path_segments & ~reserved -Tim [1] thinking of dropping "-bin" suffix for binaries. "-src" suffix for sources would be retained. [2] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonDistributio nArtifactSpecifier [3] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/JavaArtifacts [4] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/SignatureArtifact Specifier [5] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/LicenseArtifactSp ecifier [6] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier
Re: subproject URI naming convention
Tim Anderson wrote: To summarise, there are three possible ways to encode subprojects in URIs: 1. Status quo 2. Introduce mandatory path 3. Change so that it is opaque I'm beginning to prefer option 3. +1 for option 3 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
Tim Anderson wrote: The fact that commons-lang and commons-io are both part of the same Jakarta Project has no meaning to a repository. True, but users browsing the repository can find them easier if they are grouped together. The only difference between commons/lang and commons-langis the number of items in a directory. but again if we allow arbitrary number of "/" before the the artifact part how can we tell what the project is we are back to http://repo.com/alpha/beta/alpha/beta/dist/beta-alpha.zip http://repo.com/dist/nightly/dist/dist/dist/dist/foo.zip Silly examples but with out a RIGID spec it will happen. Someone will want to name thier project Alpha, or nightly or the orginaztion will be named dist or intrim or snapshot. Lets just pick a number of groupings one or two or three and stick with it. Allow the "/" to have special meaning. R, Nick
RE: subproject URI naming convention
See inline. > From: Nick Chalko [mailto:[EMAIL PROTECTED] > Sent: Thursday, 4 December 2003 6:43 PM > To: [EMAIL PROTECTED] > Subject: Re: subproject URI naming convention > > > Tim Anderson wrote: > > >3. Change so that it is opaque > > > > repository-uri = access-specifier "/" product-specifier "/" > >version-specifier "/" artifact-specifier > > product-specifier = path_segments > > > > . recommend that 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. > > > > > > > What is the minimum amount of Meta Data we can use to support this. > > I can see this as just arbitrary super-projects and a project is a dir > that has a dist directory.. or something. > > But really what is an organization. what is a project what is a > sub-project. The above doesn't try to make the distinction. It merely aims to organise the repository to better reflect project structures. In doing so, it avoids the need to come up with naming schemes like "represent subprojects by using the top level domain name for , and concatentate project and subproject names together to get ". As for meta-data - I see that as outside the scope at the moment, as tools can still: . construct URIs to unambigously locate an artifact. . parse URIs to extract project, version and artifact information. > In the end a "leaf" project is something that has distrabutables, like > jar's or zip's for source files. > Everything before that is just an arbitrary amount of grouping of projects > So really it comes down to how many levels of groups to we want 1 > or 2 or n. Yes. > The fact that commons-lang and commons-io are both part of the same > Jakarta Project has no meaning to a repository. True, but users browsing the repository can find them easier if they are grouped together. > > Because of that I still support having a specific number of non > optional project grouping levels. > I feel grouping at the organization level is enough. but I am not > against a mandatory second level but I would call it > org/project-group/project > -Tim
Re: subproject URI naming convention
Tim Anderson wrote: 3. Change so that it is opaque repository-uri = access-specifier "/" product-specifier "/" version-specifier "/" artifact-specifier product-specifier = path_segments . recommend that 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. What is the minimum amount of Meta Data we can use to support this. I can see this as just arbitrary super-projects and a project is a dir that has a dist directory.. or something. But really what is an organization. what is a project what is a sub-project. In the end a "leaf" project is something that has distrabutables, like jar's or zip's for source files. Everything before that is just an arbitrary amount of grouping of projects So really it comes down to how many levels of groups to we want 1 or 2 or n. The fact that commons-lang and commons-io are both part of the same Jakarta Project has no meaning to a repository. Because of that I still support having a specific number of non optional project grouping levels. I feel grouping at the organization level is enough. but I am not against a mandatory second level but I would call it org/project-group/project R, Nick
RE: subproject URI naming convention
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 is the reverse FQDN . for subprojects, 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 path i.e, change product-specifier: product-specifier = organisation "/" project "/" subproject . recommend that 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 so that it is opaque repository-uri = access-specifier "/" product-specifier "/" version-specifier "/" artifact-specifier product-specifier = path_segments . recommend that 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
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
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
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
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 nes
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/ | ||
