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-spe
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* a
cture currently
in use by maven (e.g http://www.ibiblio.org/maven/commons-jelly/jars/)
Regards,
Tim
> -Original Message-
> From: Tim Anderson [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 6 December 2003 4:02 AM
> To: [EMAIL PROTECTED]
> Subject: RE: subproject URI naming convention
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 bin
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
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 th
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 pro
> 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
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
>
> Tim Anderson wrote:
>
> >>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.
> ht
Tim Anderson wrote:
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
[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
_
> 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.zi
> 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 group
Tim Anderson wrote:
To summarise, there are three possible ways to encode
subprojects in URIs:
1. Status quo
2. Introduce mandatory path
3. Change so that it is opaque
I'm beginning to prefer option 3.
+1 for option 3
Steve.
--
Stephen J. McConnell
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
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 so that it is opaque
> >
> > rep
Tim Anderson wrote:
3. Change so that it is opaque
repository-uri = access-specifier "/" product-specifier "/"
version-specifier "/" artifact-specifier
product-specifier = path_segments
. recommend that contains:
. reverse FQDN
. project name
. subproject name
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 is the reverse
Nick Chalko wrote:
This is what I would recommend.
Each top level Apache project is an Orginzation.
Organitations are the reverse FQDN (so they sort)
Sub projects inside of a orginzation are seperated with - so that we
have
http://repo.apache.org/jakarta.apache.org/commons-lang
oOOPS.
http://r
This is what I would recommend.
Each top level Apache project is an Orginzation.
Organitations are the reverse FQDN (so they sort)
Sub projects inside of a orginzation are seperated with - so that we have
http://repo.apache.org/jakarta.apache.org/commons-lang
R,
Nick
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
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
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-spe
23 matches
Mail list logo
