Re: URI Syntax was: Repository
[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 the filename. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc smime.p7s Description: S/MIME Cryptographic Signature
Re: URI Syntax was: Repository
Nick Chalko <[EMAIL PROTECTED]> wrote on 31/10/2003 10:32:28 AM: > [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 > would not have the full version info. > For the dll example we can mandate that it has to be put in a versioned > zip/tar.gzip That works, but I'm still not sure why DLLs are a special case. Lots of DLLs have a version number as part of the file. What the file is called when it's downloaded is a different issue to what the file name stored in the repo is. I think the repo must stored versioned file names. > Also, some people prefer to see xalan.jar not xalan-1.4.jar. They know how to rename the file, right? > I prefer to have version in the filename. but do we want to FORCE that > on projects prublishing to our repository. Yes. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: URI Syntax was: Repository
Adam R. B. Jack wrote: I feel we could/should unashamedly complete our thoughts on Java, then go and recruit some per-language specialists to chime in on their flavour. Maybe we'll have one repository 'class' with per language sub-classes. Let's mature what we can agree upon before we specialize & determine what we can't. [If we have a Java repository separate from a C++ one, so be it, but N better than 0. Heck, separate might be easiest management anyway.] Good point. Just my two cents... regards, Adam smime.p7s Description: S/MIME Cryptographic Signature
Re: URI Syntax was: Repository
> Some artifacts don't like having the full version number. > dll for example. I think the DLL name needs to be stable and thus > would not have the full version info. > For the dll example we can mandate that it has to be put in a versioned > zip/tar.gzip If we continue to think 100% generically we'll never hold all the permutations in Wiki, let alone out heads, and we'll fluster ourselves paralysis. It is clear that Java has a set of requirements, a style, that do not fit other languages. We can't do it all. I feel we could/should unashamedly complete our thoughts on Java, then go and recruit some per-language specialists to chime in on their flavour. Maybe we'll have one repository 'class' with per language sub-classes. Let's mature what we can agree upon before we specialize & determine what we can't. [If we have a Java repository separate from a C++ one, so be it, but N better than 0. Heck, separate might be easiest management anyway.] Just my two cents... regards, Adam
Re: URI Syntax was: Repository
[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 would not have the full version info. For the dll example we can mandate that it has to be put in a versioned zip/tar.gzip Also, some people prefer to see xalan.jar not xalan-1.4.jar. I prefer to have version in the filename. but do we want to FORCE that on projects prublishing to our repository -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc smime.p7s Description: S/MIME Cryptographic Signature
Re: URI Syntax was: Repository
"Adam R. B. Jack" <[EMAIL PROTECTED]> wrote on 31/10/2003 09:10:44 AM: > Folks wrote: > Are we discussing URI or URL? If URI, ok good .. but is this current? > > I thought it was more like (w/ pseudo-regexp notation): > > http:jars/[-][-].ext 'jars' is the of the thing. e.g. jars, tlds, wars, ears, exes, bins etc. > I'm not sure I like all of that (and yes, it is Java centric) but as I > understand it, it is how the repositories currently look. >From my angle they're not java centric, it's just that most of the content is java executable code. But, for example, ibiblio has a licenses directory where jars would be, and distributions, poms etc. > 1) I could cope w/o 'jars' if that made it less Java centric. AFAIC, it's the type of the artifact. > 2) I don't like the redundant // -- it leads to the needs for > symlinks for latest (or similar). I prefer it in the filename. Once things > get copied out of a repository it is good to see what they are, fully > qualified. Ditto. [snip] -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: URI Syntax was: Repository
Nick Chalko <[EMAIL PROTECTED]> wrote on 31/10/2003 09:05:06 AM: > So here are some open questions. > > How do we pick unique human readable top level directories, in other > words how do we name the directories for projects ad sub-projects. Again, only as an example, maven takes the subproject name as the top-level name. I'm not altogether happy with it, as it makes the top level a very long list. i.e. in the maven repository, jakarta/commons/beanutils is at /commons-beanutils of the repo. > Should each version have its own subdir? My personal preference is no. I'm more often looking for a jar, version is usually a secondary consideration. > Should each artifact type have it's own subir? My preference here is yes. > Do we support both version and type subdirs. I'd prefer we make a decision one way or the other for this repository, but let the tools be flexible. > Must every artivact have the version in the file name? Definitely. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: URI Syntax was: Repository
[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 convention breaks for me. ///-. assumes that the 'project' has a single versioning system. Jakarta as a project doesn't. e.g. commons/beanutils has versions very different from commons/logging. *As an example only*, maven treats commons/beanutils and commons/logging as two separate projects. Project is a very overloaded word. What I think we are trying to describe is a "distribution unit". A set of artifacts that are released and versioned as a unit. apache-jakarta-commons-beanutils is a unit of distribution (UoD ?). We could call it beanutils, jakarta-beanutils, apache-beanutils, commons-beanutils. I like the Java package name (i.e. reverse TLD) because it is widely understood and reduce the number of conflicts. I think it is general enough that non Java projects can find a similar name org-apache-httpd-whatever R, Nick smime.p7s Description: S/MIME Cryptographic Signature
Re: URI Syntax was: Repository
Nick Chalko <[EMAIL PROTECTED]> wrote on 31/10/2003 08:38:36 AM: > >Since this is an ASF repo, isn't the ASF project name enough? > > > > > > > I think I would still prefix it with apache, so that other organizations > can follow our pattern with out conflicts. Also allowing other > repositories to host artifacts from multiple orginizations. Sounds like a good idea. > 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 convention breaks for me. ///-. assumes that the 'project' has a single versioning system. Jakarta as a project doesn't. e.g. commons/beanutils has versions very different from commons/logging. *As an example only*, maven treats commons/beanutils and commons/logging as two separate projects. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: URI Syntax was: Repository
Folks wrote: > > > > So here is a key focuossed issue. > > What should the URI look like > > > > The latest URI discussed was > > > > http:/artifact-[].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 URI, ok good .. but is this current? I thought it was more like (w/ pseudo-regexp notation): http:jars/[-][-].ext I'm not sure I like all of that (and yes, it is Java centric) but as I understand it, it is how the repositories currently look. 1) I could cope w/o 'jars' if that made it less Java centric. 2) I don't like the redundant // -- it leads to the needs for symlinks for latest (or similar). I prefer it in the filename. Once things get copied out of a repository it is good to see what they are, fully qualified. BTW: I see this more as a URL than a URI. If we are attempting a URI -- independent from actualy 'location' -- then maybe my comments are out of place. I could support an URI approach (I guess) but I wonder if then the URI ought be a higher level entity - -i.e. "the jars for project X" not named things jars. I think repository has to work at the group level, not the file level. > > The part still needs to be decided is the project name. > Since this is an ASF repo, isn't the ASF project name enough? > > > I think the most stable idea proposed is the java package name with - > > instead of . > I'd prefer to stick with the ASF project name. I can agree, it is a lot less 'fat' than package, but does it help the user enough? Say the user downloads a new project from CVS into their IDE, gets started, and finds that package org.apache.xyz is missing. How do they know that xyz is part of apache project jakarta-blah or whatever? Maybe a nice reverse map (kinda like Gump gives) would help. I feel that project name tends to push strongly towards client side metadata though, [or server side queries, I guess.] BTW: Clearly package is Java-centric. Maybe something namespaced? E.g java:org.apache.ant or something. I'm just throwing this out, I suspect project name is right, I just believe it has issues. regards Adam
Re: URI Syntax was: Repository
So here are some open questions. How do we pick unique human readable top level directories, in other words how do we name the directories for projects ad sub-projects. Should each version have its own subdir? Should each artifact type have it's own subir? Do we support both version and type subdirs. Must every artivact have the version in the file name? smime.p7s Description: S/MIME Cryptographic Signature
Re: URI Syntax was: Repository
Nick Chalko wrote: ... What should the URI look like The latest URI discussed was http:/artifact-[].ext 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 This is where Avalon keeps jars for the framework similar to the above example (done by Leo after the previous repo discussions IIUC): http://www.apache.org/dist/avalon/framework/jars/avalon-framework-4.1.jar http://www.apache.org/dist/avalon/framework/jars/avalon-framework-impl-4.1.5.jar http://www.apache.org/dist/avalon/framework/jars/LICENSE.txt So it's: http:/artifact-[].ext host: www.apache.org/dist project: avalon/framework artifact-type: jars httpd instead does this: http://www.apache.org/dist/httpd/ Please note this URL: http://www.apache.org/dist/httpd/binaries/aix/apache_1.3.26-000964804C00-ibm-aix4.3.tar.gz It could be: host: www.apache.org/dist project: httpd artifact-type: binaries/aix The tar.gz format is more complex, and needs a different version resolution system. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: URI Syntax was: Repository
[EMAIL PROTECTED] wrote: = Special versions. = Most people agree we should support Latest (released), and Nightly, along with the normal released builds Maven also has 'SNAPSHOT' which is similar in context to Nightly, but not necessarily built on a nightly basis. +1 The part still needs to be decided is the project name. Since this is an ASF repo, isn't the ASF project name enough? I think I would still prefix it with apache, so that other organizations can follow our pattern with out conflicts. Also allowing other repositories to host artifacts from multiple orginizations. 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 R, Nick PS gald we are talking about this. I find naming things to often be the hardest and most important part of a design. smime.p7s Description: S/MIME Cryptographic Signature
Re: URI Syntax was: Repository
Nick Chalko <[EMAIL PROTECTED]> wrote on 31/10/2003 05:43:38 AM: > [EMAIL PROTECTED] wrote: > > > > >Simple focussed discussion without talking about incubating projects or > >adopting projects works for me. Those are separate issues. > > So here is a key focuossed issue. > What should the URI look like > > The latest URI discussed was > > http:/artifact-[].ext > > 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-1.5.1.jar, e.g. www.apache.org/dist/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 > > > > = Special versions. = > Most people agree we should support Latest (released), and Nightly, > along with the normal released builds Maven also has 'SNAPSHOT' which is similar in context to Nightly, but not necessarily built on a nightly basis. > The part still needs to be decided is the project name. Since this is an ASF repo, isn't the ASF project name enough? > I think the most stable idea proposed is the java package name with - > instead of . I'd prefer to stick with the ASF project name. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: URI Syntax was: Repository
Noel J. Bergman wrote: The part still needs to be decided is the project name. I think the most stable idea proposed is the java package name with - instead of . Let's be careful. We should be -1 to anything that is Java-specific in such manner as to preclude non-Java projects. Rememnber: this is the ASF Repository. Good point. Other choices are reverse domain name. or apache-. Do we have anyone listening on this list from non-Java project? --- Noel smime.p7s Description: S/MIME Cryptographic Signature
RE: URI Syntax was: Repository
> The part still needs to be decided is the project name. > I think the most stable idea proposed is the java package name with - > instead of . Let's be careful. We should be -1 to anything that is Java-specific in such manner as to preclude non-Java projects. Rememnber: this is the ASF Repository. Do we have anyone listening on this list from non-Java project? --- Noel
