I changed organisation to name-segments to support structures
using reverse-FQDNs e.g:
http://repo.apache.org/org/apache
http://repo.apache.org/org/tigris
http://repo.apache.org/com/sun
while maintaining support for single segment organisation names e.g:
http://repo.apache.org/oracle
See
Tim Anderson wrote:
From a tool perspective, it can unambiguously locate a project
when given inputs of:
org.apache - must replace . with / before performing lookup
org/apache
oracle
The implication of this is that generic tools can't parse the URI
and determine what is part of the
From: Nick Chalko [mailto:[EMAIL PROTECTED]
Tim Anderson wrote:
From a tool perspective, it can unambiguously locate a project
when given inputs of:
org.apache - must replace . with / before performing lookup
org/apache
oracle
The implication of this is that generic tools
Tim Anderson wrote:
ink easing the job for tools is a good goal.
We must support both Humans and Tools.
I would favor Humans. But both humans and tools will have problems
when some orginzation decides its project name is Beta or nightly, etc
I think we should consider not allowing / in
However, I don't think this is unreasonable. There is no requirement
that tools be able to parse URIs to extract meta-data.
There is a requirement that repositories work (at some minimum level)
without metadata, especially since we aren't specifying metadata.
Without a parsable URI (or
Noel wrote:
Adam, and how is said tool going to start in the first place? Without
meta-data, there is a limit to what the tool can do. Basically, it would
have to operate relative to the URL provided to it.
My input here is primarily based on writting Ruper
(http://www.krysalis.org/ruper),
From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
snip/
You could have the client tool be told the resource/URI by the user,
and do the download/verification, yes. That said, I don't think it buys
the user enough, they have to browse/locate stash the URI in some local
config. I'd like to say
My input here is primarily based on writting Ruper
You don't have to like the tool, I'm not trying to push the implementation
I've never even seen the thing, and you are a priori assuming that I don't
like it?
It allows you to query what is there, query and capture oldest resources
[and do
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
My input here is primarily based on writting Ruper
You don't have to like the tool, I'm not trying to push the
implementation
I've never even seen the thing, and you are a priori assuming that I don't
like it?
It allows you to query
Noel wrote:
You don't have to like the tool, I'm not trying to push the
implementation
I've never even seen the thing, and you are a priori assuming that I don't
like it?
No Neol, I'm not that emoition, I meant it dispassionately and without
inference, maybe it just read differently. That
The URI proposals so far specify URIs which are
just as parseable as those currently in use by maven's
repository [1].
The only caveat is that they need to be parsed
from right to left, as the organisation [2] part of
product-specifier cannot be separated from the directory
part of
Digesting each section slowly,
Its great idea to make Artifact Specifier to be opaque to give way to
different languages, but I am not sure about the Version Specifier. Version
Specifier can be considered as language independent and allowing different
best practices in there would make the
Its great idea to make Artifact Specifier to be opaque to give way to
different languages, but I am not sure about the Version Specifier.
Version
Specifier can be considered as language independent and allowing different
best practices in there would make the repository unordered and could
13 matches
Mail list logo