You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by Tim Anderson <tm...@netspace.net.au> on 2003/12/01 04:28:41 UTC
subproject URI naming convention
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?
-Tim
[1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax
Re: subproject URI naming convention
Posted by Nick Chalko <ni...@chalko.com>.
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
"-". eg commons-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
RE: subproject URI naming convention
Posted by Matt Kurjanowicz <mk...@cc.gatech.edu>.
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:mcconnell@apache.org]
Sent: Sunday, November 30, 2003 11:26 PM
To: repository@apache.org
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/
| |
|<--------------------------->|
|
product specifier
(replacing the organization/project spec)
But I'm wondering if this will break things downstream?
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
Re: subproject URI naming convention
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
Re: subproject URI naming convention
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
Re: subproject URI naming convention
Posted by Nick Chalko <ni...@chalko.com>.
Tim Anderson wrote:
>See inline.
>
>
>
>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?
>
>
Here is one sample use case.
Delete all artifacts for none release version levels were a release
level version for the same version number is available. (ie delete
4.1beta if 4.1-final is available)
RE: subproject URI naming convention
Posted by Tim Anderson <tm...@netspace.net.au>.
See inline.
> From: Nick Chalko [mailto:nick@chalko.com]
>
> 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
Posted by Nick Chalko <ni...@chalko.com>.
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
Posted by Tim Anderson <tm...@netspace.net.au>.
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:nick@chalko.com]
> Sent: Friday, 5 December 2003 10:32 AM
> To: repository@apache.org
> 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
Posted by Nick Chalko <ni...@chalko.com>.
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
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Tim Anderson wrote:
>
> >>From: Tim Anderson [mailto:tma@netspace.net.au]
> >>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"
> >
>
> Isn't the product specifier "alpha/beta/alpha" ?
>
> Steve.
>
*Sigh* - yes, it should be.
Re: subproject URI naming convention
Posted by Stephen McConnell <mc...@apache.org>.
Tim Anderson wrote:
>>From: Tim Anderson [mailto:tma@netspace.net.au]
>>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"
>
Isn't the product specifier "alpha/beta/alpha" ?
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
RE: subproject URI naming convention
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Tim Anderson [mailto:tma@netspace.net.au]
> 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.
updated example repository structure (was RE: subproject URI naming convention)
Posted by Tim Anderson <tm...@netspace.net.au>.
I've updated the example to include versions
of commons-jelly, demonstrating the use of snapshots builds.
These are located under:
org/apache/jakarta/commons/jelly
in the archive.
It should be easier to navigate and locate snapshot and
release builds compared with the flatter structure currently
in use by maven (e.g http://www.ibiblio.org/maven/commons-jelly/jars/)
Regards,
Tim
> -----Original Message-----
> From: Tim Anderson [mailto:tma@netspace.net.au]
> Sent: Saturday, 6 December 2003 4:02 AM
> To: repository@apache.org
> Subject: RE: subproject URI naming convention
>
>
> 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)
>
RE: subproject URI naming convention
Posted by Tim Anderson <tm...@netspace.net.au>.
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:tma@netspace.net.au]
>
> > From: Nick Chalko [mailto:nick@chalko.com]
> >
> > 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.
>
RE: subproject URI naming convention
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Nick Chalko [mailto:nick@chalko.com]
>
> 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
Posted by Nick Chalko <ni...@chalko.com>.
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
RE: subproject URI naming convention
Posted by Tim Anderson <tm...@netspace.net.au>.
See inline.
> From: Nick Chalko [mailto:nick@chalko.com]
> Sent: Thursday, 4 December 2003 6:43 PM
> To: repository@apache.org
> 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
Posted by Nick Chalko <ni...@chalko.com>.
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
Posted by Tim Anderson <tm...@netspace.net.au>.
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
Posted by Nick Chalko <ni...@chalko.com>.
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://repo.apache.org/org.apache.jakarta/commons-lang
Ahh there it is REVERSE FQDN :-[
>
> R,
> Nick
>
Re: subproject URI naming convention
Posted by Nick Chalko <ni...@chalko.com>.
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