You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by Nick Chalko <ni...@chalko.com> on 2003/11/15 08:01:50 UTC
Use of '/' in ???-specifier's
Given this spec
repository-uri = access-specifier "/" product-specifier "/"
version-specifier "/" artifact-specifier
What is the version of this URL
http://repo.apache.org/org/apache/commons/nightly/alpha/1.0/foo.jar
* Projet commons, version Nightly 1.0 alpha
* Project commons-nightly, version 1.0 alpha
* Project commons-nightly-alpah version 1.0 (release)
I think we should tighten the spec enough so we can at least tell the
access, product,version, and artifact specifiers appart.
R,
Nick
Re: Use of '/' in ???-specifier's
Posted by Nick Chalko <ni...@chalko.com>.
Tim Anderson wrote:
>Alternative approaches would be to:
>. limit each *-specifier to a single path segment (i.e, disallow "/")
> Hopefully, the proposals show that this is too restrictive
>
>
>
It works the name are just very long, and thie directory listings are large.
>. include delimeters in the URI
> E.g, http://repo.apache.org/organisation/apache/project/foo/version/...
> Duplicate information, and just plain *ugly*.
>
>
>
Agree way to ugly
>-Tim
>
>
>
meta-data formats
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen,
> > The meta-data could be in the form of a POM, a JNLP file, or some other
> > format, and the tool would indicate what it is looking for as previously
> > discussed. I think that's where you're going, right?
> In principal ... yes.
> But I am making an assumption that a very simple named value pair
> metadata syntax could be assumed along with a meta mime type.
> References in that structure could be absolute or relative to the
> location of the metadata file.
That would be a possible meta-data format, but there are already others,
such as Maven's POM or Sun's JNLP. The goal, IMO, would be to provide
suitable content appropriate to the requesting client. I think we need to
facilitate the mechanism, not dictate the possible meta-data formats.
--- Noel
Re: Use of '/' in ???-specifier's
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>maybe the [organization]/[product] notion is artificial.
>>What [organization]/[product] and [organization]/[product]/[version]
>>do is to establish a path to an logical artifact.
>>
>>
>
>At any of it does is establish a path to a logical artifact. Seems to me
>that there is limited utility to being able to parse the URI, and that the
>real key is having meta-data with which to assemble it. But others don't
>seem to agree with that view. They want to parse semantic information from
>the URI.
>
>
>
>>we should not be focussing on the url as a spec - but instead
>>we should be focussing on the url as a [artifact-identifier]
>>and from that point on we should be using metadata to provide
>>us with the information about organization, product name,
>>available versions, etc.
>>
>>
>
>So your feeling is that once you have a URI for the root component for a
>tool, you want meta-data suitable for your tool to indicate the location(s)
>of other content, such as license, dependents, etc. Those location(s) can
>be specified either by a full URI, or after all of Tim's good work, by URI
>parts, which the specification tells us how to assemble. The latter is how
>I have been viewing things so far.
>
>The meta-data could be in the form of a POM, a JNLP file, or some other
>format, and the tool would indicate what it is looking for as previously
>discussed. I think that's where you're going, right?
>
In principal ... yes.
But I am making an assumption that a very simple named value pair
metadata syntax could be assumed along with a meta mime type. References
in that structure could be absolute or relative to the location of the
metadata file. Releative to the java world - that schema could be
equivalent to the Properties format (i.e. "some-name = some-value").
Given something like this - it becomes a lot simpler to seperate
mechanics of access from logic of usage, while maintaining potential for
cross-application interoperability (although that would require at least
a very very small set of standard properties - e.g. language and
application domain).
Cheers, Steve.
>>I'm not keen on being the odd-guy out
>>
>>
>
>I don't think that you are. There may be some undocumented assumptions
>going on, and this helps to clarify them. For example, the above may help
>explain to Adam why I have been unconcerned about the ability to
>unambiguously parse a URL, whereas I do care about being able to assemble
>one.
>
> --- Noel
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
Re: Use of '/' in ???-specifier's
Posted by Nick Chalko <ni...@chalko.com>.
Here is my 20 second URI
http://host/[rootdir]/Orginzation/Product/version/<type-specfiic-Artifact>
one dir each for Org, Prod, and Ver.
After that is dependent on the kind of Product. ie the java-artifact-spec.
So lets do a 20 sec java artifact spec
Stephen McConnell wrote:
>
>
> Nick Chalko wrote:
>
>> Tim Anderson wrote:
>>
>>> For advocates of URI parsing, what problems are you trying
>>> to solve?
>>>
>>>
>>>
>> * Discovery of "what is available"
>> * Repository exploring.
>> * Auto cleanup of repositories.
>>
>>
>>
>> The URI spec is too loose.
>
>
>
> I completely agree.
>
> But I just want to add that all I want is either (a) a simple
> structural spec that does not imply more the 20 mins of concentration,
> or (b) something auto-explanitory ... a.k.a. server side meta (which
> acording to me is in scope relative to the objective of qualifying and
> differentiating organization, artifact, version and all of the other
> semantics that are currently being generalized.
>
> Today - we are not in the 20 min spectrum.
>
> Stephen.
>
>
>>
>>
>> As far as I can tell these are legal
>>
>> http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar
>> http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar
>>
>>
>> We really need to harden the URI spec a little and the "/" is a good
>> start.
>>
>> R,
>> Nick
>>
>>
>
RE: Use of '/' in ???-specifier's
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Nick Chalko wrote:
>
> > Tim Anderson wrote:
> >
> >> For advocates of URI parsing, what problems are you trying
> >> to solve?
> >>
> >>
> >>
> > * Discovery of "what is available"
> > * Repository exploring.
> > * Auto cleanup of repositories.
> >
> >
> >
> > The URI spec is too loose.
>
>
> I completely agree.
>
> But I just want to add that all I want is either (a) a simple structural
> spec that does not imply more the 20 mins of concentration, or (b)
> something auto-explanitory ... a.k.a. server side meta (which acording
> to me is in scope relative to the objective of qualifying and
> differentiating organization, artifact, version and all of the other
> semantics that are currently being generalized.
>
> Today - we are not in the 20 min spectrum.
>
> Stephen.
>
I would dispute (a), but I'll admit I'm biased. The proposals
are public and can be edited and improved by anyone. If you feel there
are changes that can be made to improve readability, go ahead -
I claim no ownership - much of the content has been distilled
from earlier discussions and current ASF practices.
As for (b), put forward a proposal.
-Tim
Re: Use of '/' in ???-specifier's
Posted by Stephen McConnell <mc...@apache.org>.
Nick Chalko wrote:
> Tim Anderson wrote:
>
>> For advocates of URI parsing, what problems are you trying
>> to solve?
>>
>>
>>
> * Discovery of "what is available"
> * Repository exploring.
> * Auto cleanup of repositories.
>
>
>
> The URI spec is too loose.
I completely agree.
But I just want to add that all I want is either (a) a simple structural
spec that does not imply more the 20 mins of concentration, or (b)
something auto-explanitory ... a.k.a. server side meta (which acording
to me is in scope relative to the objective of qualifying and
differentiating organization, artifact, version and all of the other
semantics that are currently being generalized.
Today - we are not in the 20 min spectrum.
Stephen.
>
>
> As far as I can tell these are legal
>
> http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar
> http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar
>
>
> We really need to harden the URI spec a little and the "/" is a good
> start.
>
> R,
> Nick
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
Re: Use of '/' in ???-specifier's
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> Not a criticism, but I'd prefer to know the requirements,
> before writing the tools.
I know, I've been a huge advocate of that, but I'm starting to worry we are
in analysis paralysis. Logical URIs are so virtual it is easy to miss
practical implications. As such, I'd like to test the theory against "the
tool implementation in my head".
That said, we need to revisit requirements, especially the tooling aspect of
that.
As Nick said "having a tool know/display/process what is in a remote
repostiory" w/o metadata is my goal.
> As far as I can tell, maven doesn't do URI parsing.
> I don't know a lot about Gump, but if it wants to pull down the
> newest versions of jars, it can via the "latest" version tag [1].
Gump (like Maven) has metadata also, so could ask for a certain version of
something. That said, we are talking about "client side metadata" with all
of these, not "in repository metadata". As such, this information is not in
the repostory (per se) and so **not available to repository tools**. This is
the key point.
FWIIW: I *hate* maintaining version information in metadata (in CVS or not)
'cos I think it leads to stale links, and to too much duplication. I think
I've said this (once or twice ;-) before though.
BTW: I'd like the repository to work independent of client metadata, so we
have a consistent repository however tools use it. Maybe we'll have a
metadata.xml per directory that we can all agree upon, and extend, but that
isn't what we have here and now.
> Avalon adds meta-data, which is supported through
> the statement in [2]:
> "Projects should be able to deploy arbitrary artifacts to the
repository,
> whether they be for end-users, or meta-data (e.g, maven's project.xml).
> Tools should ignore any artifact they don't understand."
Yup, but I'd like to see some cross-project-type tools possible. I'd like
tools to be able to work against all types of artefacts, built by Maven, by
Gump, by whomever.
regards
Adam
Re: Use of '/' in ???-specifier's
Posted by Nick Chalko <ni...@chalko.com>.
Tim Anderson wrote:
>Not a criticism, but I'd prefer to know the requirements,
>before writing the tools.
>
>
Here is a user story.
point a "tool" at the http://repo.apache.org and have it display "what
is available"
This is much easier to do if we can tell the version from the product
from the orginzation.
R,
Nick
RE: Use of '/' in ???-specifier's
Posted by Tim Anderson <tm...@netspace.net.au>.
Not a criticism, but I'd prefer to know the requirements,
before writing the tools.
As far as I can tell, maven doesn't do URI parsing.
I don't know a lot about Gump, but if it wants to pull down the
newest versions of jars, it can via the "latest" version tag [1].
Avalon adds meta-data, which is supported through
the statement in [2]:
"Projects should be able to deploy arbitrary artifacts to the repository,
whether they be for end-users, or meta-data (e.g, maven's project.xml).
Tools should ignore any artifact they don't understand."
-Tim
[1]
http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=ASFRepository/Co
mmonBuildVersionSpecifier
[2]
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio
nSpecifier
> -----Original Message-----
> From: Adam R. B. Jack [mailto:ajack@trysybase.com]
> Sent: Tuesday, 25 November 2003 5:59 AM
> To: repository@apache.org
> Subject: Re: Use of '/' in ???-specifier's
>
>
>
> > Tim Anderson wrote:
> >
> > >For advocates of URI parsing, what problems are you trying
> > >to solve?
>
> This is a simple matter of practicality. We've agreed to delay metadata so
> we can get a nice/simple repository structure w/o all the differences of
> opinion that metadata might introduce. We basically want to take existing
> repository structures (Maven's, Avalon's, Gump's, etc.) and formalize them
> to promote consistency/re-use.
>
> We need a repository that is practical at this level, and
> practical includes
> tooling/scripting & remote/local clients. Non-parsable URIs (from a loose
> spec) mean an unreadable repository entries, so it is impractical without
> metadata. We need parsable URIs so we can have the repository by it's own
> metadata.
>
> I see your reply to Nick references additional specification. I wonder if
> they just need to merge those into the full lspecification. At
> this stage of
> development tight is far better than loose.
>
> IMHO, we can make this repository as strict as we like to start with. We
> need a tight prototypical repository, so we can build a repository and
> exercise it with tools & by hand. We can't keep going back and
> forth in the
> theoretical, we need a concrete reference, we need practical experience.
>
> regards,
>
> Adam
>
>
Re: Use of '/' in ???-specifier's
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> Tim Anderson wrote:
>
> >For advocates of URI parsing, what problems are you trying
> >to solve?
This is a simple matter of practicality. We've agreed to delay metadata so
we can get a nice/simple repository structure w/o all the differences of
opinion that metadata might introduce. We basically want to take existing
repository structures (Maven's, Avalon's, Gump's, etc.) and formalize them
to promote consistency/re-use.
We need a repository that is practical at this level, and practical includes
tooling/scripting & remote/local clients. Non-parsable URIs (from a loose
spec) mean an unreadable repository entries, so it is impractical without
metadata. We need parsable URIs so we can have the repository by it's own
metadata.
I see your reply to Nick references additional specification. I wonder if
they just need to merge those into the full lspecification. At this stage of
development tight is far better than loose.
IMHO, we can make this repository as strict as we like to start with. We
need a tight prototypical repository, so we can build a repository and
exercise it with tools & by hand. We can't keep going back and forth in the
theoretical, we need a concrete reference, we need practical experience.
regards,
Adam
Re: Use of '/' in ???-specifier's
Posted by Nick Chalko <ni...@chalko.com>.
Tim Anderson wrote:
>>From: Nick Chalko [mailto:nick@chalko.com]
>>
>>Tim Anderson wrote:
>>
>>
>>
>>>>http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar
>>>>http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar
>>>>
>>>>We really need to harden the URI spec a little and the "/" is a
>>>>good start.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>I missed that the "jars" or type dir was required.
>>what about,
>>
>>http://repo.apache.org/1/2/3/4/5/6/7/8/pgp/KEYS
>>http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/pgp/KEYS
>>I suppose this is the version named Alpha of the alpha/alpha project.
>>Or is it the alpha release of the version named alpha of the
>>project named alpha or..
>>
>>
>>These are silly examples, but lets try to prevent at least some of them.
>>
>>
>>
>
>OK. If the organisation is limited back to a single path segment,
>and assuming the repository is rooted at http://repo.apache.org,
>then the above would be invalid as the:
>. first 2 path segments are the organisation and project
>. 3rd path segment is the version (limited to 1 segment as it doesn't
> meet the criteria for interim builds [1])
>. last 2 path segments are the key-artifact artifact-specifier [2]
>
>
>
So above would be
http://repo.apache.org/alpha.alpha/alpha.alpha/alpha/pgp/KEYS
is valid, still silly but easy to tell the org, product and version.
>-Tim
>
>[1]
>http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio
>nSpecifier
>[2] Not in wiki yet:
>http://nagoya.apache.org/eyebrowse/ReadMsg?listName=repository@apache.org&ms
>gNo=423
>
>
>
RE: Use of '/' in ???-specifier's
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Nick Chalko [mailto:nick@chalko.com]
>
> Tim Anderson wrote:
>
> >>http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar
> >>http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar
> >>
> >>We really need to harden the URI spec a little and the "/" is a
> >>good start.
> >>
> >>
> >>
> >
> >
> >
> I missed that the "jars" or type dir was required.
> what about,
>
> http://repo.apache.org/1/2/3/4/5/6/7/8/pgp/KEYS
> http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/pgp/KEYS
> I suppose this is the version named Alpha of the alpha/alpha project.
> Or is it the alpha release of the version named alpha of the
> project named alpha or..
>
>
> These are silly examples, but lets try to prevent at least some of them.
>
OK. If the organisation is limited back to a single path segment,
and assuming the repository is rooted at http://repo.apache.org,
then the above would be invalid as the:
. first 2 path segments are the organisation and project
. 3rd path segment is the version (limited to 1 segment as it doesn't
meet the criteria for interim builds [1])
. last 2 path segments are the key-artifact artifact-specifier [2]
-Tim
[1]
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio
nSpecifier
[2] Not in wiki yet:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=repository@apache.org&ms
gNo=423
Re: Use of '/' in ???-specifier's
Posted by Nick Chalko <ni...@chalko.com>.
Tim Anderson wrote:
>>http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar
>>http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar
>>
>>We really need to harden the URI spec a little and the "/" is a
>>good start.
>>
>>
>>
>
>
>
I missed that the "jars" or type dir was required.
what about,
http://repo.apache.org/1/2/3/4/5/6/7/8/pgp/KEYS
http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/pgp/KEYS
I suppose this is the version named Alpha of the alpha/alpha project.
Or is it the alpha release of the version named alpha of the project named alpha or..
These are silly examples, but lets try to prevent at least some of them.
>The above a legal for the URI Syntax proposal [1], but illegal
>according to the common build version [2] and java artifact specifiers [3].
>Tools based on [2] & [3] should ignore them.
>
>Is it simply a matter of restricting organisation back to a single
>path segment? This would allow product-specifier to be determined
>by parsers.
>
>
Yes that is the start, make org and product un ambigous is a really
good start.
>Note that this was the original approach, but some people expressed a
>desire to be able to break down the hierarchy using reverse-FQDNs.
>
>
I still think reverse-FQDN is a good idea but for parsability I would
use . not /
RE: Use of '/' in ???-specifier's
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Nick Chalko [mailto:nick@chalko.com]
>
> Tim Anderson wrote:
>
> >For advocates of URI parsing, what problems are you trying
> >to solve?
> * Discovery of "what is available"
> * Repository exploring.
> * Auto cleanup of repositories.
>
> The URI spec is too loose.
>
> As far as I can tell these are legal
>
> http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar
> http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar
>
> We really need to harden the URI spec a little and the "/" is a
> good start.
>
The above a legal for the URI Syntax proposal [1], but illegal
according to the common build version [2] and java artifact specifiers [3].
Tools based on [2] & [3] should ignore them.
Is it simply a matter of restricting organisation back to a single
path segment? This would allow product-specifier to be determined
by parsers.
Note that this was the original approach, but some people expressed a
desire to be able to break down the hierarchy using reverse-FQDNs.
As for auto cleanup, this is supported in part by:
. version-specifier in [1]
"All repository URIs must include a version in the path. This:
. ensures all artifacts for a particular version are grouped together
. simplifies archival of artifacts for a particular version"
. interim-build in [2]
This assigns timestamps for interim builds (nightly, snapshot etc)
The repository would have to limit version naming schemes to
numeric schemes to support auto cleanup fully, which is too restrictive IMO.
-Tim
[1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Proposals
[2]
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio
nSpecifier
[3] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/JavaArtifacts
Re: Use of '/' in ???-specifier's
Posted by Nick Chalko <ni...@chalko.com>.
Tim Anderson wrote:
>For advocates of URI parsing, what problems are you trying
>to solve?
>
>
>
* Discovery of "what is available"
* Repository exploring.
* Auto cleanup of repositories.
The URI spec is too loose.
As far as I can tell these are legal
http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar
http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar
We really need to harden the URI spec a little and the "/" is a good start.
R,
Nick
RE: Use of '/' in ???-specifier's
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Nick Chalko [mailto:nick@chalko.com]
>
> Noel J. Bergman wrote:
>
> >Seems to me
> >that there is limited utility to being able to parse the URI,
> and that the
> >real key is having meta-data with which to assemble it. But others don't
> >seem to agree with that view. They want to parse semantic
> information from
> >the URI.
> >
>
> The semantic information is there in the URL, org. project. version,
> artifact type, name, release type etc.
> People WILL try to parse it. I think it would be a Good Idea to make
> it easy to parse at least the major pieces into discrete chunks.
>
> Assuming most people will simply replace "/" with "-" or "_" the issue
> is not one off URL length or URL readability, it seems to be mostly
> about the browseablity of of directories.
> In other words have all the apache projects under the apache dir, or
> under subdirs of apache.
>
> I think the convience of knowing exactly where org, project, and
> version start and stop is worth the cost to browseablity.
>
The proposals aim to structure the repository such that:
1. artifacts can easily be located by users
2. artifacts can easily be located by tools
For [2], the intention is that a maven-like approach
will be used for artifact resolution i.e, the
user specifies enough criteria to enable a tool
to unambigously locate an artifact.
This approach doesn't require artifact URIs to be parsed.
For advocates of URI parsing, what problems are you trying
to solve?
-Tim
Re: Use of '/' in ???-specifier's
Posted by Nick Chalko <ni...@chalko.com>.
Noel J. Bergman wrote:
>Seems to me
>that there is limited utility to being able to parse the URI, and that the
>real key is having meta-data with which to assemble it. But others don't
>seem to agree with that view. They want to parse semantic information from
>the URI.
>
>
>
The semantic information is there in the URL, org. project. version,
artifact type, name, release type etc.
People WILL try to parse it. I think it would be a Good Idea to make
it easy to parse at least the major pieces into discrete chunks.
Assuming most people will simply replace "/" with "-" or "_" the issue
is not one off URL length or URL readability, it seems to be mostly
about the browseablity of of directories.
In other words have all the apache projects under the apache dir, or
under subdirs of apache.
I think the convience of knowing exactly where org, project, and
version start and stop is worth the cost to browseablity.
R,
Nick
RE: Use of '/' in ???-specifier's
Posted by "Noel J. Bergman" <no...@devtech.com>.
> maybe the [organization]/[product] notion is artificial.
> What [organization]/[product] and [organization]/[product]/[version]
> do is to establish a path to an logical artifact.
At any of it does is establish a path to a logical artifact. Seems to me
that there is limited utility to being able to parse the URI, and that the
real key is having meta-data with which to assemble it. But others don't
seem to agree with that view. They want to parse semantic information from
the URI.
> we should not be focussing on the url as a spec - but instead
> we should be focussing on the url as a [artifact-identifier]
> and from that point on we should be using metadata to provide
> us with the information about organization, product name,
> available versions, etc.
So your feeling is that once you have a URI for the root component for a
tool, you want meta-data suitable for your tool to indicate the location(s)
of other content, such as license, dependents, etc. Those location(s) can
be specified either by a full URI, or after all of Tim's good work, by URI
parts, which the specification tells us how to assemble. The latter is how
I have been viewing things so far.
The meta-data could be in the form of a POM, a JNLP file, or some other
format, and the tool would indicate what it is looking for as previously
discussed. I think that's where you're going, right?
> I'm not keen on being the odd-guy out
I don't think that you are. There may be some undocumented assumptions
going on, and this helps to clarify them. For example, the above may help
explain to Adam why I have been unconcerned about the ability to
unambiguously parse a URL, whereas I do care about being able to assemble
one.
--- Noel
Re: Use of '/' in ???-specifier's
Posted by Stephen McConnell <mc...@apache.org>.
Tim Anderson wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Nick Chalko wrote:
>>
>>
>>
>>>Given this spec
>>>repository-uri = access-specifier "/" product-specifier "/"
>>> version-specifier "/" artifact-specifier
>>>
>>>
>>>What is the version of this URL
>>>http://repo.apache.org/org/apache/commons/nightly/alpha/1.0/foo.jar
>>> * Projet commons, version Nightly 1.0 alpha
>>> * Project commons-nightly, version 1.0 alpha
>>> * Project commons-nightly-alpah version 1.0 (release)
>>>
>>>I think we should tighten the spec enough so we can at least tell the
>>>access, product,version, and artifact specifiers appart.
>>>
>>>
>>+1
>>
>>Steve.
>>
>>
>>
>
>A repository URI cannot be parsed simply based on <repository-uri>.
>It needs to be used in conjunction with the other proposals before
>any information can be derived.
>
>As stated previously, the URI doesn't match the criteria supported
>by the other proposals. This doesn't mean that the URI is invalid,
>it simply means that it isn't supported by them.
>Tools that are based on the proposals should therefore ignore it.
>
>Alternative approaches would be to:
>. limit each *-specifier to a single path segment (i.e, disallow "/")
> Hopefully, the proposals show that this is too restrictive
>
>. include delimeters in the URI
> E.g, http://repo.apache.org/organisation/apache/project/foo/version/...
> Duplicate information, and just plain *ugly*.
>
Tim:
I'm really not agree or disagreeing at this time - I just have a feeling
in my bones that something is wrong. As such - consider this as simple
rambling by someone who has not captured the big picture.
After heading down to the cafe for a quick break - when walking back my
thinking is that maybe the [organization]/[product] notion is
artificial. What [organization]/[product] and
[organization]/[product]/[version] do is to establish a path to an
logical artifact. I can't get away from that conclusion that we should
not be focussing on the url as a spec - but instead we should be
focussing on the url as a [artifact-identifier] and from that point on
we should be using metadata to provide us with the information about
organization, product name, available versions, etc.
But this presuposes that atrifact is something more abstract than a file
- and I'm guessing that your idea of artifact is equivalent to file.
Appologies here because I'm not keen on being the odd-guy out - and I
don;t want to disrupt the flow. But at the same time I want to see a
good result from this. And from that point of view - my own feeling is
that we should *not* be focussing on the url as the base layer - but
instead focus on what is the meta descriptor and its MIME relationship
*then*focusus on how to access this via a url. But I could easily be
totally wrong because I'm still in digesting/thinking mode.
Cheers, Steve.
>
>-Tim
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
RE: Use of '/' in ???-specifier's
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Nick Chalko wrote:
>
> > Given this spec
> > repository-uri = access-specifier "/" product-specifier "/"
> > version-specifier "/" artifact-specifier
> >
> >
> > What is the version of this URL
> > http://repo.apache.org/org/apache/commons/nightly/alpha/1.0/foo.jar
> > * Projet commons, version Nightly 1.0 alpha
> > * Project commons-nightly, version 1.0 alpha
> > * Project commons-nightly-alpah version 1.0 (release)
> >
> > I think we should tighten the spec enough so we can at least tell the
> > access, product,version, and artifact specifiers appart.
>
>
> +1
>
> Steve.
>
A repository URI cannot be parsed simply based on <repository-uri>.
It needs to be used in conjunction with the other proposals before
any information can be derived.
As stated previously, the URI doesn't match the criteria supported
by the other proposals. This doesn't mean that the URI is invalid,
it simply means that it isn't supported by them.
Tools that are based on the proposals should therefore ignore it.
Alternative approaches would be to:
. limit each *-specifier to a single path segment (i.e, disallow "/")
Hopefully, the proposals show that this is too restrictive
. include delimeters in the URI
E.g, http://repo.apache.org/organisation/apache/project/foo/version/...
Duplicate information, and just plain *ugly*.
-Tim
Re: Use of '/' in ???-specifier's
Posted by Stephen McConnell <mc...@apache.org>.
Nick Chalko wrote:
> Given this spec
> repository-uri = access-specifier "/" product-specifier "/"
> version-specifier "/" artifact-specifier
>
>
> What is the version of this URL
> http://repo.apache.org/org/apache/commons/nightly/alpha/1.0/foo.jar
> * Projet commons, version Nightly 1.0 alpha
> * Project commons-nightly, version 1.0 alpha
> * Project commons-nightly-alpah version 1.0 (release)
>
> I think we should tighten the spec enough so we can at least tell the
> access, product,version, and artifact specifiers appart.
+1
Steve.
>
>
> R,
> Nick
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
Re: Use of '/' in ???-specifier's
Posted by Nick Chalko <ni...@chalko.com>.
Nick Chalko wrote:
> Tim Anderson wrote:
>
>>>
>>>
>>
>>
>> The URI isn't valid, according to
>>
>> http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio
>>
>> nSpecifier
>>
>>
>>
>> -Tim
>>
>>
>>
>
> Try this one
>
> http://repo.apache.org/org/apache/commons/alpha/1.0/foo.jar
>
> * Projet commons, version 1.0 alpha
> * Project commons-alpha, version 1.0
> * Project alpha version 1.0
>
>
> I know this is contrived, but it does highlight the inablity to tell
> where one specifier ends, and onther begins.
> R,
> Nick
>
>
>
Ooops still not "valid"
but this one may be perhaps we can always parse this right to left.
R,
Nick
Re: Use of '/' in ???-specifier's
Posted by Nick Chalko <ni...@chalko.com>.
Tim Anderson wrote:
>>
>>
>>
>
>The URI isn't valid, according to
>
>http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio
>nSpecifier
>
>
>
>-Tim
>
>
>
Try this one
http://repo.apache.org/org/apache/commons/alpha/1.0/foo.jar
* Projet commons, version 1.0 alpha
* Project commons-alpha, version 1.0
* Project alpha version 1.0
I know this is contrived, but it does highlight the inablity to tell
where one specifier ends, and onther begins.
R,
Nick
RE: Use of '/' in ???-specifier's
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Nick Chalko [mailto:nick@chalko.com]
>
> Given this spec
>
> repository-uri = access-specifier "/" product-specifier "/"
> version-specifier "/" artifact-specifier
>
>
> What is the version of this URL
> http://repo.apache.org/org/apache/commons/nightly/alpha/1.0/foo.jar
>
> * Projet commons, version Nightly 1.0 alpha
> * Project commons-nightly, version 1.0 alpha
> * Project commons-nightly-alpah version 1.0 (release)
>
> I think we should tighten the spec enough so we can at least tell the
> access, product,version, and artifact specifiers appart.
>
> R,
> Nick
>
The URI isn't valid, according to
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio
nSpecifier
as a nightly build is an interim build:
interim-build = interim-build-designation "/" version
[ "/" interim-version ]
interim-version = "latest" | YYYYMMDD ["-" HHMM [SS]]
interim-build-designation = "interim" | "nightly" | "snapshot" | ...
version = "latest" | *pchar
IOW, one of "alpha" or "1.0" is invalid.
However, given the URI:
http://repo.apache.org/org/apache/commons/nightly/1.0/20031113/jars/foo-1.0.
jar
it is possible to determine the version using the common build version
specifier and java artifact specifier proposals, by parsing the URI
from right to left.
It isn't possible to separate the organisation from the directory
component of access-specifier however.
e.g. given:
http://repo.apache.org/org/apache/
it could be interpreted as:
. directory = "org", organisation = "apache"
. directory = "", organisation = "org/apache"
-Tim