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 *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

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 /
 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

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

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 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

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
. 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

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

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 organisation, and concatentate project and
subproject names together to get project.

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

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-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

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 PROTECTED]
||
| Magic by Merlin|
| Production by Avalon   |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/   |
||




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 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

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
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

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
_
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

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

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

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 / 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

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

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