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 p
> 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 th
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 man
> > >However, I don't think this is unreasonable. There is no requirement
> > >that tools be able to parse URIs to extract meta-data.
Say who?
There is a requirement that repositories "work" (at some minimum level)
without metadata, especially since we aren't specifying metadata. Without a
parsab
> > 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
Overview
This proposal extends the URI Syntax proposal, v0.2:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&ms
gNo=367
The key aims of this proposal are to:
. formalise version-specifier for projects which
provide formal and interim builds;
. provide a set of best practices fo
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)
Tim,
I *love* your specifications, I really appreciate the clear/concise/explicit
nature of them. I only wish you'd use Wiki not EyeBrowse as your persistent
documentation tool. Wiki has versioning (so we can see older copies should
we need to refer back) and such, and allows other to make (respec
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
> 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
On Fri, 14 Nov 2003 08:16 pm, Michal Maczka wrote:
> >The only purpose of "type" in maven is to indicate how it is processed by
> > the runtime. (ie plugins get installed, jars get added to classpath etc).
> > It does not even specify that extension as there is a M-to-M between type
> > and extensi
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 15 November 2003 2:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [proposal] common build version specifier - v0.1
>
>
> Tim,
>
> I *love* your specifications, I really appreciate the
> clear/concise/explicit
> nature of them. I only
> From: Peter Donald [mailto:[EMAIL PROTECTED]
>
> On Fri, 14 Nov 2003 08:16 pm, Michal Maczka wrote:
> > >The only purpose of "type" in maven is to indicate how it is
> processed by
> > > the runtime. (ie plugins get installed, jars get added to
> classpath etc).
> > > It does not even specify
> 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"
> [an
One of the current problems with repositories such
as http://www.ibiblio.org/maven is their inability
to host products which have restrictive licensing schemes.
(See http://maven.apache.org/sun-licensing-journey.html for background)
E.g, ibiblio cannot host jars from Sun, because of the
requiremen
> 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
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
* Proje
> From: Nick Chalko [mailto:[EMAIL PROTECTED]
>
> 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
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,
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
* Pro
Tim Anderson wrote:
...
Virtual hosting
---
With this approach, none of the artifacts are hosted within the
public repository.
http redirection is used to direct 'virtual' artifact accesses to
the real artifact.
The limitation of this approach is that automatic artifact resolution
ca
Overview
This proposal extends the URI Syntax proposal:
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax
It is recommended, but not required, that it be used in conjunction
with the Common Build Version Specifier proposal:
http://nagoya.apache.org/wiki/apachewiki.c
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. Th
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 access-specifie
24 matches
Mail list logo
