This seems like a whole lot of XML for what is implicit in the URI and
the manifest.
Ted Leung wrote:
Hi guys,
I know I'm late to the party, but...
I know that we're discussing URI format and Andy's writing code, and I have
some code as well. One thing
that I haven't seen here is what functionality we want to enable by having a
repository.Here are some possible
pieces:
1. Be
we call for a VOTE so we can move on?
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
-
Costin Manolache wrote:
On Tue, 8 Apr 2003, Nick Chalko wrote:
I almost missed this thread.
The jar repository issue continues.
Except it's no longer the jar repository issue :-)
Just use the /dist layout the way it is supposed to - i.e
to distribute our releases.
Jars are just one type
Here is the goals I think we shouould have for a project reference scheme.
* Human Readable
* globaly unique
* stable over long periods of time
If these are reasonable goals, then we should start evalutating the
merrits of different approaches.
R,
Nick
smime.p7s
Description: S/MIME
Adam R. B. Jack wrote:
Let's try to work this one through to completion:
http://host/group/type/id[-version].ext
So what should group be
Given Noel's concern about Top Level Project and projects moving. I
think that leaves us with the java package name. Allowing non java
groups to use
Adam R. B. Jack wrote:
Metadata:
3) Do we need per version metadata? Hmmm... :(
I guess it's doable, tools could easily provide. The per id *.md5 or *.asc
are such metadata.
I think per version metadata can be just another TYPE of artifact
stored in the repo
Anou Manavalan wrote:
With repositories growing fast, it needs to be searched and there
should be a keyword search that assists faster search ( speaking from
the established UDDI Repository and Database point of view ).
With no responses supporting this idea, I guess I will put this idea
to
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
artifact aquisition
[EMAIL PROTECTED] wrote:
Start at, and hack away.
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository
Nick, what's the wiki link?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Nick Chalko
Lets try to summerize the different positions and then come to a
consensus on the wiki at
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/WhereIsVersionInURISytnax
I am still trying to wade throught the 60 emails from this weekend. I
would really appreciate the various pro's and
Michal Maczka wrote:
I wrote:
.. repository [...] won't be limited to projects hosted at ASF.
In requirement list I can see:
ASF Repository shall not
Host any artifact in violation of a license, or IPR.
And if anything was discussed before - above statement reflects well the
temporary decision
Lets see where we stand on the version.
Please go to
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/WhereIsVersionInURISytnax
and vote for the Proposal you prefer.
Add pro's and con's as you see fit.
Lets see how close we are to a consensus so wee can move on to other
parts of the
Current count.
2 For version dir with optional version on artifact name.
3 for version dir and versioned artifact name.
Make sure you voice your opinion.
Nick Chalko wrote:
Lets see where we stand on the version.
Please go to
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository
, this then leads to the possibility of nightly,
snapshot, release etc being mandatory in product-specifier:
product-specifier = organisation / project / rtype / version
rtype = nightly | snapshot | release | ...
-Tim
-Original Message-
From: Nick Chalko [mailto:[EMAIL PROTECTED]
Sent: Friday
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.
Is that a
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
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
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
* Project
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,
Noel J. Bergman wrote:
Seems to me
that there is limited utility to being able to parse the URI, and that the
real key is having meta-data with which to assemble it. But others don't
seem to agree with that view. They want to parse semantic information from
the URI.
The semantic information
Tim Anderson wrote:
This group could make recommendations as to how
virtual artifacts could be supported.
Agree that we should deal with license issue's and virutal artifacts
when we take on metadata.
Tim Anderson wrote:
Can you clarify the licensing issues further? I'm having trouble
seeing what the problems are.
Suppose ASF has the following link in the repository:
http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar
This is a virtual artifact, not hosted at ASF.
I think what you
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.
As far as I can tell these are legal
Tim Anderson wrote:
http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar
http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar
We really need to harden the URI spec a little and the / is a
good start.
I missed that the jars or type dir was required.
what about,
Tim Anderson wrote:
From: Nick Chalko [mailto:[EMAIL PROTECTED]
Tim Anderson wrote:
http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar
http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar
We really need to harden the URI spec a little and the / is a
good start.
I missed
Tim Anderson wrote:
Not a criticism, but I'd prefer to know the requirements,
before writing the tools.
Here is a user story.
point a tool at the http://repo.apache.org and have it display what
is available
This is much easier to do if we can tell the version from the product
from the
Here is my 20 second URI
http://host/[rootdir]/Orginzation/Product/version/type-specfiic-Artifact
one dir each for Org, Prod, and Ver.
After that is dependent on the kind of Product. ie the java-artifact-spec.
So lets do a 20 sec java artifact spec
Stephen McConnell wrote:
Nick Chalko wrote:
Tim
[EMAIL PROTECTED] wrote:
I agree it would be a nice to have, but is it a requirement for an ASF
repo?
Agree, lets wrap up the other specs first. I think we should delay,
but a week or two maybe enough.
Comment on the / issue. Help decidce in the version name not allowing
release or
Excelent work. I think this a very manageable set of specs.
I have one question for the
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersionSpecifier
MileStone builds (ala eclipse) are they a formal or interm. Interm I think.
R
Nick
Tim Anderson wrote:
3. Change product-specifier so that it is opaque
repository-uri = access-specifier / product-specifier /
version-specifier / artifact-specifier
product-specifier = path_segments
. recommend that product-specifier contains:
. reverse FQDN
.
Tim Anderson wrote:
The fact that commons-lang and commons-io are both part of the same
Jakarta Project has no meaning to a repository.
True, but users browsing the repository can find them easier if
they are grouped together.
The only difference between
commons/lang and commons-lang
Tim Anderson wrote:
Can you provide an example of a URI which can't be parsed?
-Tim
[1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax
*repository-uri = access-specifier / product-specifier /
version-specifier / artifact-specifier*
It defines *access-specifier* and
Patrick Chanezon wrote:
Did you specify a lifecycle for artifacts, with some durations, and a
process to decommision them ?
Good question. This may be something to put to the board.
My general thought are.
Released version should live forever, unless a security or other fatal
flaw is found
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
Adam R. B. Jack wrote:
I could possibly tweek it to not send an email if there are no new
files being moved.
Please do.
regards
Adam
I am +1 to send the notices here if the mail is tweaked .
smime.p7s
Description: S/MIME Cryptographic Signature
37 matches
Mail list logo