RE: subproject URI naming convention

2003-12-05 Thread Anou Manavalan
Dropping it just for binaries may be fine, but it is nice to have for src 
and others, since the src and the bin mostly have the same name doesn't 
seem right.

Can be added as an optional one.
regards,
-Anou

From: "Tim Anderson" <[EMAIL PROTECTED]>
Reply-To: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: RE: subproject URI naming convention
Date: Fri, 5 Dec 2003 09:18:46 +1100
> 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

_
Wonder if the latest virus has gotten to your computer? Find out. Run the 
FREE McAfee online computer scan! 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963



RE: subproject URI naming convention

2003-12-05 Thread Tim Anderson
Attached is an archive which shows a sample repository structure
where the product-specifier contains >= 2 path segments.

Hopefully, this will carify things.

It contains:
. ant versions 1.5.2, 1.5.3-1, 1.5.4 and nightlies of 1.6alpha
. httpd 2.0.48
. jms 1.1
. jndi 1.2.1
. commons-collections 1.0, 2.0
. commons-cli 1.0, nightlies of 1.0 and 2.0
. commons-betwixt 1.0-alpha-1, nightlies of 1.0-beta-1-dev

(all sample files are empty)

-Tim

> From: Tim Anderson [mailto:[EMAIL PROTECTED]
>
> > 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.
>


repo.tar.gz
Description: Binary data


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