Leo:
Can you confirm that the following Maven dependency declaration would be
consistent with what you are proposing - I'm using the
cornerstone-threads package as an example where we have mixed artifacts
relative to a group.
cornerstone-threads
cornerstone-threads-api
1.0
cor
Adam R. B. Jack wrote:
Three comments (probably all repetitions) :
1) Perl/Python have a package index/identification approaches. We might want
a similar concept, i.e. queriable metadata that associates keywords/concepts
with packages/groups/artefacts. These concepts could be language sensitive
(s
Jason van Zyl wrote:
On Fri, 2003-11-07 at 11:48, Stephen McConnell wrote:
Adam R. B. Jack wrote:
Three comments (probably all repetitions) :
1) Perl/Python have a package index/identification approaches. We might want
a similar concept, i.e. queriable metadata that associates keywords
Jason van Zyl wrote:
On Fri, 2003-11-07 at 15:38, Stephen McConnell wrote:
Jason van Zyl wrote:
On Fri, 2003-11-07 at 11:48, Stephen McConnell wrote:
Adam R. B. Jack wrote:
Three comments (probably all repetitions) :
1) Perl/Python have a package index/identification
Anou Manavalan wrote:
With no responses supporting this idea, I guess I will put this idea
to rest in peace ;-)
Searching is certainly on the my agenda. We need it for IDE related
development, repository management, and intelligent query based artifact
aquisition (and HTTP in this context is
Nick Chalko wrote:
Stephen McConnell wrote:
Anou Manavalan wrote:
With no responses supporting this idea, I guess I will put this idea
to rest in peace ;-)
Searching is certainly on the my agenda. We need it for IDE related
development, repository management, and intelligent query based
Adam R. B. Jack wrote:
It's really not that much more than that.
Sophisticated systems that are reliable are built upon simplicity not
complexity
I agree. I'd like to think of what we are doing as laying out a simple file
system, and later building services that index/query. Compare this to
/
Jason van Zyl wrote:
Component deployment and an applications use of a repository are irrelavent;
An applications use of a repository represent real and tangible examples
of expected utility - i.e. actual functional requirements.
Sure "get me a versioned artefact of a particular type" is a priva
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 H
Jason van Zyl wrote:
On Sat, 2003-11-08 at 21:47, Stephen McConnell wrote:
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
Jason van Zyl wrote:
On Sat, 2003-11-08 at 23:18, Stephen McConnell wrote:
Jason van Zyl wrote:
I have challenged you to give me a scenerio that I can't satisfy with
something like the current Maven repository. Instead you drone on ad
nauseum about the theoretical. Let
Jason van Zyl wrote:
On Sun, 2003-11-09 at 00:35, Stephen McConnell wrote:
Jason:
I must confess that I am intrigued by your approach to collaboration!
That's because you're at least as deficient as I am in the realm of
collaboration. Neither you or I are any great shining exam
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 don
Jason van Zyl wrote:
On Sun, 2003-11-09 at 01:08, Stephen McConnell wrote:
Jason van Zyl wrote:
On Sun, 2003-11-09 at 00:35, Stephen McConnell wrote:
Jason:
I must confess that I am intrigued by your approach to collaboration!
That's because you're a
peter royal wrote:
On Nov 7, 2003, at 5:37 PM, Stephen McConnell wrote:
Searching is certainly on the my agenda. We need it for IDE related
development, repository management, and intelligent query based
artifact aquisition (and HTTP in this context is not an ideal solution).
But that
[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:
http://www.ibiblio.org/maven
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
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 addin
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 etc
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
Michal Maczka wrote:
IMHO "type" directory should be mandatory
+1
We should always use:
http://repo.apache.org/apache/ant/1.5.4/keys/KEYS-1.5.4
More rules and exceptions will make entire process harder from point
of view of tools.
My proposition is:
repository-uri = access-specifier "/" prod
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
ig up
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
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 or not
Tim:
My initial impression is that all the following could be expressed as
part of a spec. one-level-up from the artifact spec. Everything below
is dealing with the notion of the usage of the repository for a
particular purpose - namely the registration of artifacts arising from
development pr
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 b
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
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
htt
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 limite
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 wa
Tim:
Short note to let you know that I updated ASFRepository/JavaArtifacts
to include the Avalon bar file as a java-artifact-specifier. I think
that this latest spec is looking a lot more robust - thanks for the
effort on this.
Cheers, Steve.
Tim Anderson wrote:
I've updated the proposals to incorp
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 "/" artifact-spe
Tim Anderson wrote:
To summarise, there are three possible ways to encode
subprojects in URIs:
1. Status quo
2. Introduce mandatory path
3. Change so that it is opaque
I'm beginning to prefer option 3.
+1 for option 3
Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
|-
Tim Anderson wrote:
From: Tim Anderson [mailto:[EMAIL PROTECTED]
Sent: Friday, 5 December 2003 8:35 AM
Damn - forgot version in artifact name...
[snip]
Some examples, using valid URIs:
1. http://repo.com/alpha/beta/alpha/1.0/binaries/beta-alpha-1.0.zip[1]
artifact-specifier = "binaries
37 matches
Mail list logo
