Re: What should be in the MetaData

On Thu, 6 Mar 2003, Andrew C. Oliver wrote: I don't really intend to have an english discussion on this, I would rather discuss in Java. I'm approximately 3-5 days away from having this done... I have a feeling that if people would first discuss things in english we wouldn't have the current me

Re: What should be in the MetaData

Nick Chalko wrote: This seems like a whole lot of XML for what is implicit in the URI and the manifest. You mean the very specific to one server and one layout? Your goals may differ. Thats fine. -Andy

Re: Organization Identifiers - URI Syntax

I agree that this is a good idea, with the adddtion of version http:// where artifact may optionally have a version suffix such as ant-1.5.jar O'brien, Tim wrote: We should try to have an organization identifier of something like "org-apache", or "org.apache". This shouldn't be confused with

Organization Identifiers - URI Syntax

We should try to have an organization identifier of something like "org-apache", or "org.apache". This shouldn't be confused with Java package naming conventions. Repository discussions should get bogged down in references to JARs, I see this repository URI syntax as being technology neutral. Ar

Re: What should be in the MetaData

This seems like a whole lot of XML for what is implicit in the URI and the manifest.

Re: What should be in the MetaData

This seems like a whole lot of HTML for what is implicit in the URI and the manifest.

Re: URI syntax

On Thu, 6 Mar 2003, Nick Chalko wrote: > Is a mandatory version dir and a optional version suffix on artifacts ok? > > /project/version/artifact[-version].jar Or ( as is current practice ): /project-version/artifact[-version].jar Again: my main concern with [-version].jar is the lack of cons

Re: What should be in the MetaData

:-( oh man... did ya have to? I don't really intend to have an english discussion on this, I would rather discuss in Java. I'm approximately 3-5 days away from having this done... The code goes and grabs a version of a jar based on 4 XML descriptors (don't take these as gospel, they are chang

MetaData requirements was: What should me in the MetaData

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

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 a eas

Re: What should me in the MetaData

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 a easy-to-

What shall we use for as the project name part of the URI

This seems to be the main part of the URI that needs work Requirements * Each Apache project shall have a unique name in the repository * The name should be stable so the URI for artifacts have a long life. * The name should be easy to guess by humans and machines. -- Nick Chalko

Re: URI syntax

Costin Manolache wrote: I don't think package name is a good idea - you may have multiple packages, it doesn't allways match the project name,etc. snip IMHO we should try to keep things as simple as possible. The only important and critical decision is if we want version number in the jar o

Re: URI syntax

On Thu, 6 Mar 2003, Dirk-Willem van Gulik wrote: > > > > Why not use the package name with '/' instead of '.', e.g. > > > > org/ > > apache/ > > ant/ > > 1.5.1/ > > avalon/ > > commons/ > > httpclient/ > > 2.0/ > > > > etc? > > I'd like that structure - but st

What should be in the MetaData

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 Ant +

What should me in the MetaData

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

Dirk-Willem van Gulik wrote: http:/artifact-[].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 Why go st

Re: URI syntax

> http:/artifact-[].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 Why go straight to the ja

Re: URI syntax

> Why not use the package name with '/' instead of '.', e.g. > > org/ > apache/ > ant/ > 1.5.1/ > avalon/ > commons/ > httpclient/ > 2.0/ > > etc? I'd like that structure - but still would argue that returning a piece of metadata is propably better - and taking

RE: Using daedalus to deploy the httpclienttest.war

> We are looking for a public tomcat container that we can deploy into. > Would it be possible to do this on daedalus? This should be on infrastructure@, not [EMAIL PROTECTED] In any event, moof or nagoya would be more appropriate than daedalus. The infrastructure team can make the call on which

Re: URI syntax

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 browse-abl

Re: URI syntax

Well originally the artifact was under version -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Nick Chalko <[EMAIL PROTECTED]> wrote on 06/03/2003 04:32:06 PM: > [EMAIL PROTECTED] wrote: > > >Why not use the

RE: test

Yes. It has been a bit quiet for the past few days. --- Noel

Re: URI syntax

[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: Using daedalus to deploy the httpclienttest.war

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.wa

Re: URI syntax

Why not use the package name with '/' instead of '.', e.g. org/ apache/ ant/ 1.5.1/ avalon/ commons/ httpclient/ 2.0/ etc? -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Nick C

Re: Using daedalus to deploy the httpclienttest.war

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 contai

Re: URI syntax

http:/artifact-[].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 still needs to be decided is

Re: test

Andrew C. Oliver wrote: tap tap tapis this thing on? yes

test

tap tap tapis this thing on?