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
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
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
Re: subproject URI naming convention
Tim Anderson wrote: 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. 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
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
Tim Anderson wrote: To summarise, there are three possible ways to encode subprojects in URIs: 1. Status quo 2. Introduce mandatory subproject path 3. Change product-specifier 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
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
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
[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
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
