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
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 /
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
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
.
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
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
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
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
[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
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 /
: 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
11 matches
Mail list logo