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:[EMAIL
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 /
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
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
Tim Anderson wrote:
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
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
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
Just based on opinions registered so far - it seems that the notion of
version in the path has concensus and that the real question and
difference between the two position holding attention is if a version in
the filename should be manadatory or not.
Is that a reasonable conclusions?
Stephen.
Nick Chalko wrote:
Stephen McConnell wrote:
Just based on opinions registered so far - it seems that the notion
of version in the path has concensus and that the real question and
difference between the two position holding attention is if a version
in the filename should be manadatory
Tim Anderson wrote:
OK - so it should be at part of the java artifact specifier proposal [1],
or do you envision another layer?
I don't think this is java specific - its software development process
specific. My current thinking is that it is a langauge independent
layer is sufficient (mainly
some more on on content negotiation subject as this may be a factor in
resolving some of the requirements I have.
Stephen.
Noel J. Bergman wrote:
Stephen McConnell asked:
File system - a convenient and simple solution - but should a file
system driven approach be the basis for the next
Leo Simons wrote:
Justin Erenkrantz wrote:
Do any 'core' infrastructure people need to get involved to help
guide with what's practical or not?
yep. But I doubt you really need to get 'deeply' involved. A half-page
explanation of what resources are and are not available should be
enough, don't
Tim Anderson wrote:
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Tim Anderson wrote:
I take the view that everything in the repository is an artifact.
Tools can exclude the artifacts they don't need - there can't be any
language agnostic support for this, without adding metadata
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 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
Roy T. Fielding wrote:
Small note - some of the participants on the [EMAIL PROTECTED] are
discussing the actual requirements - which from my (and other) point(s)
of view go beyond a file-system http protocol cut-and-dried
implementation
solution. Some consider this area to be much more than an
Roy T. Fielding wrote:
It is about safe downloading of dependencies from a virtual
repository that extends across mirrored systems on a heterogeneous,
multi-organizational network. The underlying infrastructure is
going to be file based because it will be replicated with rsync.
I sure as hell
[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
Tim Anderson wrote:
I take the view that everything in the repository is an artifact.
Tools can exclude the artifacts they don't need - there can't be any
language agnostic support for this, without adding metadata.
Tim:
How do you address something like the following:
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
20 matches
Mail list logo
