> 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


Reply via email to