Dion,
Is there a reason why a project's repository URI cannot be orthogonal to
whatever file system naming convention is adopted for downloadable parts? I
think that it has to be orthogonal if we are to federate with other
repositories without having to incorporate them by value. And it
On Sat, 1 Mar 2003 [EMAIL PROTECTED] wrote:
Having a file encode project-artifact-version.type has been very useful
for us.
Yes, it's often different from what the project creates and distributes, but
I (and others)
have been bitten by
commons-logging.jar, struts.jar, junit.jar so many
On Sat, 2003-03-01 at 11:12, Costin Manolache wrote:
On Sat, 1 Mar 2003 [EMAIL PROTECTED] wrote:
It is also redundant information - each jar has a well-defined Manifest
that should include version.
Unfortunately practice and observation show this not to be the case in
many situations.
On Sat, 1 Mar 2003, Stefano Mazzocchi wrote:
Date: Sat, 01 Mar 2003 12:08:36 +0100
From: Stefano Mazzocchi [EMAIL PROTECTED]
Reply-To: community@apache.org
To: community@apache.org
Subject: Re: [proposal] daedalus jar repository
[EMAIL PROTECTED] wrote:
As an aside, one of the issues
[EMAIL PROTECTED] wrote:
Nick,
can you explain why there is a need for a subproject and not a
sub-subproject etc?
Good question.
This also releates to what is a project . Jakarta , avalon, turbine.
poi, poi-contrib.
On the one hand we could allow unlimited subprojects. specify that
Craig R. McClanahan wrote:
On Sat, 1 Mar 2003, Stefano Mazzocchi wrote:
[EMAIL PROTECTED] wrote:
Having a file encode project-artifact-version.type has been very
useful for us.
Yes, it's often different from what the project creates and distributes,
but I (and others) have been bitten by
i think that maybe organization / project would be better that
/project/[subproject/..].
i think that including organization would a good idea for a couple of
reasons. first, it would make it pretty clear that it's an URI is for an
ASF jar. secondly, it would allow expansion later for non-ASF
Guys, does this have much to do with 'community' anymore? From what
I've read, it looks like a Java specific project.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl:
Nick,
Two problems here
* The uri to find a needed jar.
* How to store the jar on the local filesystem
Does the URI (request) and descriptor (response) solution I proposed not
address those goals? That approach decoupled the naming systems.
--- Noel
i think that maybe organization / project would be better that
/project/[subproject/..].
More stable, less fragile. Still provides for qualified the naming space,
and is more in keeping with how we've been doing package naming.
I don't know if it needs to be a directory hierarchy, though.
Wouldn't a reasonable approach to this problem be to make searches for
commons-foo.jar return the latest released version, while searches for
commons-foo-x.y.jar would return that particular version? Then, you can
have it either way. On the former, one might also support a mode that
grabs
11 matches
Mail list logo
