Re: [proposal] daedalus jar repository

2003-03-02 Thread Nick Chalko
) they (the tools) will come. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nick Chalko Show me the code

URI syntax

2003-03-02 Thread Nick Chalko
The consensus seems to be forming around a basic URI of /project/version/artifact such as http://repo.apache.org/org.apache.ant/1.5/ant.jar -- Nick Chalko Show me the code. Centipede Ant + autodownloadable build plugins + needed

Re: URI syntax

2003-03-06 Thread Nick Chalko
http://host/project/version/artifact-[version].ext Seems to be a reasonable compromise. 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 http://repo.apache.org/org-apache-ant/1.5.1/LICENSE.txt The part

Re: Using daedalus to deploy the httpclienttest.war

2003-03-06 Thread Nick Chalko
War's, like jars are the kind of artifacts that the ASF repository should support. Jandalf wrote: Commons HttpClient comes with a very large JUnit test suite (some 250 tests). Approx 100 of those are webapp tests that require the httpclienttest.war file to be deployed in a application

Re: Using daedalus to deploy the httpclienttest.war

2003-03-06 Thread Nick Chalko
Ahh I misread deploy war Nick Chalko wrote: War's, like jars are the kind of artifacts that the ASF repository should support. Jandalf wrote: Commons HttpClient comes with a very large JUnit test suite (some 250 tests). Approx 100 of those are webapp tests that require the httpclienttest.war

Re: URI syntax

2003-03-06 Thread Nick Chalko
[EMAIL PROTECTED] wrote: Why not use the package name with '/' instead of '.', e.g. org/ apache/ ant/ 1.5.1/ avalon/ commons/ httpclient/ 2.0/ etc? The /project/version/artifact/ is trivial to identifiy the version part. Hmm. Would version always be the last directory?

Re: URI syntax

2003-03-06 Thread Nick Chalko
repo-location/project/version/artifact Where repo-location is a valid URI such ad http://repo.apahce.org/public/ project is any valid path such as org/apache/commons-cli and version as any valid path excluding '/'. And artifact is any valid file. Still keeps the parser simple. And it is

Re: URI syntax

2003-03-06 Thread Nick Chalko
use all that information but I also want to support get href=http://repo.apache.org/org-apache-ant/LATEST/ant.jar; / Lets start a sperate thread on what should be in the metadata. -- Nick Chalko Show me the code. Centipede Ant

What should me in the MetaData

2003-03-06 Thread Nick Chalko
I'll start the discussion with what John Toohey said. In both html and xml format * list of available versions, * their MD5's, * dependencies, * perhpas a * code for licenses -- Nick Chalko Show me the code. Centipede

Re: URI syntax

2003-03-06 Thread Nick Chalko
. Costin -- Nick Chalko Show me the code. Centipede Ant + autodownloadable build plugins + needed jars autodownload. http://krysalis.org/centipede -

Re: What should be in the MetaData

2003-03-06 Thread Nick Chalko
Costin Manolache wrote: On Thu, 6 Mar 2003, Nick Chalko wrote: I'll start the discussion with what John Toohey said. In both html and xml format * list of available versions, * their MD5's, * dependencies, * perhpas a * code for licenses Html format - I suppose you mean

MetaData requirements was: What should me in the MetaData

2003-03-06 Thread Nick Chalko
What are the requirements for MetaData The meta data should support: * identifectoin of dependineces * version information * JDK level requirements * integrity check What else/

Re: What should be in the MetaData

2003-03-06 Thread Nick Chalko
This seems like a whole lot of XML for what is implicit in the URI and the manifest.

Re: [proposal] repository URI format

2003-03-08 Thread Nick Chalko
Excelent elongated summart. Thanks Leo. :-)

Re: [proposal] repository URI format

2003-03-10 Thread Nick Chalko
Leo Simons wrote: Use case: build.xml - !-- use ant 1.5.1 -- project target name=download-somefile get src=http://something.easy/somefile.jar; dest=lib/somefile.jar / /target target name=compile depends=download-somefile !-- blah -- /target /project I think this is

Re: What does the repository enable?

2003-03-10 Thread Nick Chalko
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

Re: [proposal] repository URI format

2003-03-10 Thread Nick Chalko
Andrew C. Oliver wrote: I think this is an esential usecase That is why I support the URI first then XML path. Your itch, not mine. I do agree that we need the your stuff also, especailly in centipede. see http://www.krysalis.org/cgi-bin/krywiki.pl?MetaDepend I want to the other use case

Re: [proposal] URI format

2003-03-19 Thread Nick Chalko
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 -

Re: [Fwd: Re: [VOTE] distribute the compiled .jar binaries as part of the /dist]

2003-04-09 Thread Nick Chalko
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

URL Syntax was: URI Syntax

2003-10-30 Thread Nick Chalko
Adam R. B. Jack wrote: Folks wrote: So here is a key focuossed issue. 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 Are we discussing URI or URL? If

How to reference projects in the Repository.

2003-10-30 Thread Nick Chalko
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

Re: URI Syntax was: Repository

2003-10-30 Thread Nick Chalko
[EMAIL PROTECTED] wrote: There is still some naming details to work out. An apache project can be a very big thing. Take the CLI project in Jakarta commons that would be apache-jakarta-commons-cli vs the pacakge name org.apache.commons.cli This is where the previous naming

Re: URI Syntax was: Repository

2003-10-30 Thread Nick Chalko
[EMAIL PROTECTED] wrote: Nick Chalko [EMAIL PROTECTED] wrote on 31/10/2003 09:05:06 AM: Must every artivact have the version in the file name? Definitely. Some artifacts don't like having the full version number. dll for example. I think the DLL name needs to be stable and thus

URL Syntax parts

2003-10-31 Thread Nick Chalko
Here is a fresh stab at what we are talking about. I see the URL sytax having these parts rootdistribution-unittypeversioned artifact Sample http://repo.apache.org/jakarta/commons-beanutils/jars/commons-beantutils-1.4.jar * root o http://repo.apache.org/jakarta * Distribution Unit

Re: Argrement #1? : Layout (aka URL)

2003-10-31 Thread Nick Chalko
Adam R. B. Jack wrote: Let's try to work this one through to completion: http://host/group/type/id[-version].ext Should be http://host/group/type/id-version.ext Version must be somewere in the path. smime.p7s Description: S/MIME Cryptographic Signature

re Group was Argrement #1? : Layout (aka URL)

2003-10-31 Thread Nick Chalko
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

Re: Argrement #1? : Layout (aka URL)

2003-10-31 Thread Nick Chalko
Noel J. Bergman wrote: http://host/group/type/id-version.ext Version must be somewere in the path. Why? I think Adam has a pretty good starting point. And although a .ext is going to be common, we should drop it as a requirement: http://host/group/type/id[-version][.ext] --- Noel I

Re: metadata

2003-10-31 Thread Nick Chalko
Adam R. B. Jack wrote: Metadata: Since we need/want programmable I doubt we'll get disagreement on XML. Static or dynamic is more interesting. I think we should have meta data, but I would like a repo to still be usable at some level with out any. Just drop files in a dir on a webserver

Re: metadata

2003-10-31 Thread Nick Chalko
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

Re: URI Syntax was: Repository

2003-10-31 Thread Nick Chalko
[EMAIL PROTECTED] wrote: I prefer to have version in the filename. but do we want to FORCE that on projects prublishing to our repository. Yes. Ok I think we can concur. and add this to the requirement/ Goals doc All artifacts in the repository WILL include the version in

Repo Goals

2003-11-07 Thread Nick Chalko
Here is the currently listed goals http://nagoya.apache.org/wiki/apachewiki.cgi?action=editid=ASFRepository bGoal:/b A repository architecture/implmentation for software artifacts (primarily JARs) for streamlining distribution. Corrolary Goal: Removing JARs from CVS. * Open (language

Re: Proposals

2003-11-07 Thread Nick Chalko
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

Re: Proposals

2003-11-07 Thread Nick Chalko
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

Re: Road Map

2003-11-08 Thread Nick Chalko
[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

Where to put Version in the URISyntax

2003-11-10 Thread 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

Re: Processing Versions

2003-11-10 Thread Nick Chalko
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

[VOTE] Where is version in UIR Syntax

2003-11-13 Thread Nick Chalko
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

Re: [VOTE] Where is version in UIR Syntax

2003-11-13 Thread Nick Chalko
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

Re: [VOTE] Where is version in UIR Syntax

2003-11-14 Thread Nick Chalko
, 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

Re: [VOTE] Where is version in UIR Syntax

2003-11-14 Thread Nick Chalko
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

Re: URI Syntax: nightly and release builds

2003-11-14 Thread Nick Chalko
Tim Anderson wrote: The URISyntax proposal is silent on how to handle nightly, release, snapshot, and latest builds. This should be formalised. Very nicley thought out proposal. However first we should decide if we need to do anything with version. Why can't projects just all there versions

Re: [proposal] URI Syntax - v0.2

2003-11-15 Thread Nick Chalko
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

Re: [proposal] URI Syntax - v0.2

2003-11-15 Thread Nick Chalko
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

Use of '/' in ???-specifier's

2003-11-15 Thread Nick Chalko
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

Re: Use of '/' in ???-specifier's

2003-11-15 Thread Nick Chalko
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,

Re: Use of '/' in ???-specifier's

2003-11-18 Thread Nick Chalko
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

Re: click through license support?

2003-11-20 Thread Nick Chalko
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.

Re: licensing issues for virtual artifacts (was RE: click through license support?)

2003-11-21 Thread Nick Chalko
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

Re: Use of '/' in ???-specifier's

2003-11-24 Thread Nick Chalko
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

Re: Use of '/' in ???-specifier's

2003-11-24 Thread Nick Chalko
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,

Re: Use of '/' in ???-specifier's

2003-11-24 Thread Nick Chalko
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

Re: Test/Prototypical Repository

2003-11-24 Thread Nick Chalko
Look reasonable to me. Adam R. B. Jack wrote: All, As a way to force me to review the specification and attempt to implement I've started a knock up repository at: http://www.apache.org/~ajack/testrepo [If we think this is a good idea we can ask infrastructure@ for a location we can all write

Re: Use of '/' in ???-specifier's

2003-11-24 Thread Nick Chalko
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

Re: Use of '/' in ???-specifier's

2003-11-25 Thread Nick Chalko
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

Re: licensing issues for virtual artifacts (was RE: click through license support?)

2003-11-25 Thread Nick Chalko
[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

Re: URI proposals updated

2003-11-29 Thread Nick Chalko
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

Re: subproject URI naming convention

2003-12-04 Thread Nick Chalko
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 .

Re: subproject URI naming convention

2003-12-04 Thread Nick Chalko
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

Re: subproject URI naming convention

2003-12-04 Thread Nick Chalko
version-name = pchar+ ~(formal-build-designation | interim-build-designation | latest) artifact-specifier = path_segments With the N levels of grouping you must look FIND the version in the middle somewhere but version-name can be jar or apache or jars or foo and the path_segments in the

Re: subproject URI naming convention

2003-12-08 Thread Nick Chalko
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

Re: subproject URI naming convention

2003-12-01 Thread Nick Chalko
Understanding that we are at the detail level and any of this will work. The two questions up are org/proj and allowing and/or forcing org/proj/sub-proj. I have made the case in the past for not allowing arbitrary / in part names because it makes the URI hard to parse. Not hard to generate

Re: cool uris don't change, don't they ?

2004-02-03 Thread Nick Chalko
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

Re: cool uris don't change, don't they ?

2004-02-03 Thread Nick Chalko
be automated based on historical download information on the resource. I.E. if the resource hasn't been downloaded in 5 years, move it into an archive and provide a redirect or notice. -Mark Nick Chalko wrote: Patrick Chanezon wrote: Did you specify a lifecycle for artifacts, with some durations

Re: URI syntax

2004-05-04 Thread Nick Chalko
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

Re: URI syntax

2004-05-04 Thread Nick Chalko
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

Re: URI syntax

2004-05-04 Thread Nick Chalko
Yes I like your suggestions, update the webpage, but I would annotate your additions as TIPS or HINTS Michael Davey wrote: Hello, I'd like to suggest some changes to the URI Syntax document: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax In the Product specifier

Trusting md5

2004-07-15 Thread Nick Chalko
I just wanted to walk through the steps need to trust a md5 signature, using mirrors. Given a unified directory/ repository structure between mirrors and the official source. Here is what I think the steps are 1. User/tools visits the official repository for a resource, and gets a list

Re: Rsync Emails

2004-08-04 Thread Nick Chalko
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