Michael Davey wrote:
I'd suggest that the change to project be a mandate. The change
could be considered a clarification to improve consistency in naming.
The alternative would be to let, say, Commons Net define their project
as commons-net while Commons IO may choose to call their project
Disregard, I miss read this.
Nick Chalko wrote:
Michael Davey wrote:
I'd suggest that the change to project be a mandate. The change
could be considered a clarification to improve consistency in
naming. The alternative would be to let, say, Commons Net define
their project as commons-net
://repo.apache.org/org/apache/commons-logging
this makes more sense as org / project
http://repo.apache.org/org-apache/commons-logging
regards,
-Anou
From: Tim Anderson [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [proposal] URI Syntax - v0.2
Date: Fri, 14 Nov 2003 16
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
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.
As for the particular examples you gave, those carry semantic meaning that
would require more specification that is contained in the URI syntax.
Although those
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
I've restructured the wiki page at
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/WhereIsVersionInU
RISytnax,
and removed the part about symbolic links.
-Tim
-Original Message-
From: Nick Chalko [mailto:[EMAIL PROTECTED]
Sent: Friday, 14 November 2003 11:00 AM
To: [EMAIL
The URISyntax proposal is silent on how to handle
nightly, release, snapshot, and latest builds.
This should be formalised.
The current proposal has:
product-specifier = organisation / project / version
where:
version = *pchar
To support nightlies etc, this leads to the possibility of
because I think I have resolved how to do
everything I want relative to java based on these two layers).
The URI Syntax proposal [2] that the above extends is becoming a little
thin.
That's fine.
It just means we have a simple and specific specification dealing with a
simple and specific
Anderson [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [proposal] URI Syntax - v0.2
Date: Fri, 14 Nov 2003 16:39:06 +1100
This version replaces v1.0:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]ms
gNo=308
Overview
The key aims of this proposal
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
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Tim Anderson wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
From the requirements at
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements:
ASF Repository shall ... allow browsing and downloading of artifacts by
Tim Anderson wrote:
By implication - the README is not an artifact but a feature of a version.
Is that a reasonable conclusion?
Stephen.
Why make the distinction? I view everything a project deploys as an
artifact. Some artifacts will only be useful to end users (e.g,
README, LICENSE.txt
Woops - see small correction in line.
Stephen McConnell wrote:
Tim Anderson wrote:
By implication - the README is not an artifact but a feature of a
version.
Is that a reasonable conclusion?
Stephen.
Why make the distinction? I view everything a project deploys as an
artifact. Some artifacts
Tim Anderson [EMAIL PROTECTED] wrote on 10/11/2003 10:53:47 AM:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
From the requirements at
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements:
ASF Repository shall ... allow browsing and downloading of
artifacts
Stephen McConnell [EMAIL PROTECTED] wrote on 10/11/2003 10:58:09 AM:
By implication - the README is not an artifact but a feature of a
version.
Is that a reasonable conclusion?
I'd question the value of distributing a README as a single file.
In the maven world, we have a type called
Tim Anderson wrote:
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Woops - see small correction in line.
Stephen McConnell wrote:
Tim Anderson wrote:
By implication - the README is not an artifact but a feature of a
version.
Is that a reasonable conclusion?
Stephen.
http://repo.apache.org/apache/commons-logging/1.0.3/index.html
Clearly, this is only useful to users browsing the repository,
and therefore makes no sense to include the version information.
On index.html, wouldn't we discourage the use of this? Wouldn't we want the
HTTP server to do a
On Sun, 2003-11-09 at 01:41, Tim Anderson wrote:
I have a few comments on the proposed URI Syntax, from
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax.
quote
Compromise URI
http://host/project/version/artifact-[version;].ext
For example
http
Where is Tim's Layout?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Noel J. Bergman [EMAIL PROTECTED] wrote on 09/11/2003 06:22:51 PM:
Jason,
I think that Tim's ideas were pretty
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]ms
gNo=266
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sunday, 9 November 2003 7:28 PM
To: [EMAIL PROTECTED]
Subject: RE: Comments on URI Syntax
Where is Tim's Layout?
--
dIon Gillard, Multitask
On Sun, 2003-11-09 at 02:22, Noel J. Bergman wrote:
Jason,
I think that Tim's ideas were pretty well-thought out and reflect a workable
consensus. The changes you are making to his ideas, if I read the
correctly, are to mandate a couple of things that he did not rule out, but
permitted to
[EMAIL PROTECTED] wrote:
From the requirements at
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements:
ASF Repository shall ... allow browsing and downloading of artifacts by
humans via normal
web browser.
Requiring a version to be part of the artifact file name when the
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
From the requirements at
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements:
ASF Repository shall ... allow browsing and downloading of artifacts by
humans via normal
web browser.
Requiring a version to be part of
Tim Anderson wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
From the requirements at
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements:
ASF Repository shall ... allow browsing and downloading of artifacts by
humans via normal
web browser.
Requiring a version
Some artifacts don't like having the full version number.
dll for example. I think the DLL name needs to be stable and thus
would not have the full version info.
For the dll example we can mandate that it has to be put in a versioned
zip/tar.gzip
If we continue to think 100% generically
Nick Chalko wrote:
...
What should the URI look like
The latest URI discussed was
http://host/project/version/artifact-[version].ext
For example
* http://repo.apache.org/org-apache-ant/1.5.1/ant-1.5.1.jar
* http://repo.apache.org/org-apache-ant/1.5.1/ant-testutil-1.5.1.jar
*
Nick Chalko [EMAIL PROTECTED] wrote on 31/10/2003 08:38:36 AM:
Since this is an ASF repo, isn't the ASF project name enough?
I think I would still prefix it with apache, so that other organizations
can follow our pattern with out conflicts. Also allowing other
repositories to host
On Thu, 6 Mar 2003, Nick Chalko wrote:
Is a mandatory version dir and a optional version suffix on artifacts ok?
/project/version/artifact[-version].jar
Or ( as is current practice ):
/project-version/artifact[-version].jar
Again: my main concern with [-version].jar is the lack of
36 matches
Mail list logo
