Re: subproject URI naming convention

2003-12-08 Thread Nick Chalko
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

RE: subproject URI naming convention

2003-12-08 Thread Tim Anderson
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 /

RE: subproject URI naming convention

2003-12-04 Thread Tim Anderson
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

Re: subproject URI naming convention

2003-12-04 Thread Nick Chalko
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 .

Re: subproject URI naming convention

2003-12-04 Thread Nick Chalko
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

Re: subproject URI naming convention

2003-12-04 Thread Stephen McConnell
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

RE: subproject URI naming convention

2003-12-04 Thread Tim Anderson
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

RE: subproject URI naming convention

2003-12-04 Thread Tim Anderson
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

RE: subproject URI naming convention

2003-12-04 Thread Anou Manavalan
[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

Re: subproject URI naming convention

2003-12-01 Thread Stephen McConnell
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 /

RE: subproject URI naming convention

2003-12-01 Thread Matt Kurjanowicz
: 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