Re: URI/URL Syntax -- little nits to be aware of
Tim Anderson wrote: From: Stephen McConnell [mailto:[EMAIL PROTECTED] Tim Anderson wrote: I take the view that everything in the repository is an artifact. Tools can exclude the artifacts they don't need - there can't be any language agnostic support for this, without adding metadata. Tim: How do you address something like the following: http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar.md5 I don't see the md5 file as an artifact - instead I consider it to be meta data about the jar artifact. The md5 file is an artifact. Its meta data for the jar, for those tools that understand it. OK - this view of artifact seems to be equivalent to file. Here we have an example where a file type of .jar matches a type seperator. In the case of the MD5 file it does not. This difference is what destinguishes the MD5 from the jar. As such - I think we can say that the file matching the type context is the artifact and that files that don;t match and are in the same directory represent meta data about the artifact. But this would require some adjustments on what is and isn't an artifact. -Tim PS - is anyone else having problems with this list? I never received my original response to this. This is the only response to this message that I have seen. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
RE: Comments on URI Syntax
From: Stephen McConnell [mailto:[EMAIL PROTECTED] Tim Anderson wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] From the requirements at http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements: ASF Repository shall ... allow browsing and downloading of artifacts by humans via normal web browser. Requiring a version to be part of the artifact file name when the artifact is only useful to end users (e.g README), reduces clarity. But it does increase usability sometimes. README for which version? An example: http://repo.apache.org/apache/commons-dbcp/1.1/README The README is for version 1.1 of commons-dbcp. By implication - the README is not an artifact but a feature of a version. Is that a reasonable conclusion? Stephen. Why make the distinction? I view everything a project deploys as an artifact. Some artifacts will only be useful to end users (e.g, README, LICENSE.txt etc), others will be useful to tools. -Tim
Re: Comments on URI Syntax
Tim Anderson wrote: By implication - the README is not an artifact but a feature of a version. Is that a reasonable conclusion? Stephen. Why make the distinction? I view everything a project deploys as an artifact. Some artifacts will only be useful to end users (e.g, README, LICENSE.txt etc), others will be useful to tools. Because there is difference between aggregation of files of a partiular type as distinct from files that describe a particular typed file instance. I view the artifact as the principal file held in a directory qualifed by a type (e.g. the jar file in a jars directory), and that other resources such as READMEs, LICENSEs, MD5s, etc. are examples of data that describe features of specific things such as a group, version, artifact, etc. Why make the distinction? When I look at the available artifacts in a /jars/ directory I will present these as an list of artifacts. A user may select to view the properties/features of one of these items. Using the name of an artifact - I can locate additional information about the artifact such as the MD5 signature, maybe the license or some dependency information - providing there is a convention that is predictable. I.e. I need a mechanism to locate information about a particular artifact - e.g. artifact-path.something artifact-path.something-else artifact-path.MD5 artifact-path.README Etc. Stephen. -Tim -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
Re: Comments on URI Syntax
Woops - see small correction in line. Stephen McConnell wrote: Tim Anderson wrote: By implication - the README is not an artifact but a feature of a version. Is that a reasonable conclusion? Stephen. Why make the distinction? I view everything a project deploys as an artifact. Some artifacts will only be useful to end users (e.g, README, LICENSE.txt etc), others will be useful to tools. Because there is difference between aggregation of files of a partiular type as distinct from files that describe a particular typed file instance. I view the artifact as the principal file held in a directory qualifed by a type (e.g. the jar file in a jars directory), and that other resources such as READMEs, LICENSEs, MD5s, etc. are examples of data that describe features of specific things such as a group, version, artifact, etc. Why make the distinction? When I look at the available artifacts in a /jars/ directory I will present these as an list of artifacts. A user may select to view the properties/features of one of these items. Using the name of an artifact - I can locate additional information about the artifact such as the MD5 signature, maybe the license or some dependency information - providing there is a convention that is predictable. I.e. I need a mechanism to locate information about a particular artifact - e.g. I left out the all important principal artifact. artifact-path.type- the principal artifact (e.g. jars/fred.jar) artifact-path.something -- some metadata artifact-path.something-else -- more meta data artifact-path.MD5 --- artifact signature artifact-path.README readme about the artifact The important thing is the recognition of the difference between a file that *is* the artifact as distinct from a file that *describes* an artifact. Stephen. artifact-path.something artifact-path.something-else artifact-path.MD5 artifact-path.README Etc. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
RE: Comments on URI Syntax
Tim Anderson [EMAIL PROTECTED] wrote on 10/11/2003 10:53:47 AM: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] From the requirements at http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements: ASF Repository shall ... allow browsing and downloading of artifacts by humans via normal web browser. Requiring a version to be part of the artifact file name when the artifact is only useful to end users (e.g README), reduces clarity. But it does increase usability sometimes. README for which version? An example: http://repo.apache.org/apache/commons-dbcp/1.1/README The README is for version 1.1 of commons-dbcp. That's easy enough to work out from the URL, what happens after I've downloaded it? In the case of a README, you'd hope it contained some version info anyways, but for other stuff? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: Comments on URI Syntax
Stephen McConnell [EMAIL PROTECTED] wrote on 10/11/2003 10:58:09 AM: By implication - the README is not an artifact but a feature of a version. Is that a reasonable conclusion? I'd question the value of distributing a README as a single file. In the maven world, we have a type called 'distribution', which contains a README, jar, source etc. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: Comments on URI Syntax
Tim Anderson wrote: From: Stephen McConnell [mailto:[EMAIL PROTECTED] Woops - see small correction in line. Stephen McConnell wrote: Tim Anderson wrote: By implication - the README is not an artifact but a feature of a version. Is that a reasonable conclusion? Stephen. Why make the distinction? I view everything a project deploys as an artifact. Some artifacts will only be useful to end users (e.g, README, LICENSE.txt etc), others will be useful to tools. Because there is difference between aggregation of files of a partiular type as distinct from files that describe a particular typed file instance. I view the artifact as the principal file held in a directory qualifed by a type (e.g. the jar file in a jars directory), and that other resources such as READMEs, LICENSEs, MD5s, etc. are examples of data that describe features of specific things such as a group, version, artifact, etc. Why make the distinction? When I look at the available artifacts in a /jars/ directory I will present these as an list of artifacts. A user may select to view the properties/features of one of these items. Using the name of an artifact - I can locate additional information about the artifact such as the MD5 signature, maybe the license or some dependency information - providing there is a convention that is predictable. I.e. I need a mechanism to locate information about a particular artifact - e.g. I left out the all important principal artifact. artifact-path.type- the principal artifact (e.g. jars/fred.jar) artifact-path.something -- some metadata artifact-path.something-else -- more meta data artifact-path.MD5 --- artifact signature artifact-path.README readme about the artifact The important thing is the recognition of the difference between a file that *is* the artifact as distinct from a file that *describes* an artifact. Stephen. artifact-path.something artifact-path.something-else artifact-path.MD5 artifact-path.README Etc. Stephen. File aggregation is important to tools, less so for end-users. The MD5 is just another artifact - its up to the tools to determine its association with other artifacts. If the MD5 is just another artifact then it would belong under something like: http://www.ibiblio.org/maven/ant/md5s/some-artifact-name.md5 But that does not make sence (or types don't make sence). The fact is that there really is a differnce between path and path.meta providing that there that is a recognition in the base repository schema that these are two different things. That recognition (as a part of the schema) is very important for the attribution of information that would be used in the next level up - i.e. that leyer on which meta data is accesses to in order to manage an anttribute. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
[proposal] java artifact specifier v0.1
Overview The aim of this proposal is to specify the URI syntax for artifacts for java-based projects. It extends the URI syntax proposal: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]ms gNo=308 Java project artifacts include, but are not limited to: jars, wars, rars, tlds, source and binary distributions, and licenses. URI Components -- An absolute repository URI is written as follows: repository-uri = access-specifier / product-specifier / artifact-specifier For java artifacts, artifact-specifier is: artifact-specifier = [type /] artifact type = jars | wars | rars | tlds | binaries | source | licenses | ... artifact = artifact-name [- version] [- stype][.ext] artifact-name = *pchar stype = bin | src ext = jar | war | rar | tld | tar.gz | zip | ... Checksums PGP signatures -- All artifacts may have an associated md5 checksum, of the form: artifact-specifier .md5 or a PGP signatures, of the form: artifact-specifier .asc Examples jars: http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar.md5 http://repo.apache.org/apache/ant/1.5.4/jars/ant-optional-1.5.4.jar http://repo.apache.org/apache/ant/1.5.4/jars/ant-optional-1.5.4.jar.md5 binaries: http://repo.apache.org/apache/ant/1.5.4/binaries/ant-1.5.4-bin.zip http://repo.apache.org/apache/ant/1.5.4/binaries/ant-1.5.4-bin.zip.md5 http://repo.apache.org/apache/ant/1.5.4/binaries/ant-1.5.4-bin.tar.gz http://repo.apache.org/apache/ant/1.5.4/binaries/ant-1.5.4-bin.tar.gz.asc source: http://repo.apache.org/apache/ant/1.5.4/source/ant-1.5.4-src.zip http://repo.apache.org/apache/ant/1.5.4/source/ant-1.5.4-src.zip.md5 http://repo.apache.org/apache/ant/1.5.4/source/ant-1.5.4-src.tar.gz http://repo.apache.org/apache/ant/1.5.4/source/ant-1.5.4-src.tar.gz.asc licenses: http://repo.apache.org/apache/ant/1.5.4/licenses/LICENSE.txt PGP keys: http://repo.apache.org/apache/ant/1.5.4/KEYS
Re: URI/URL Syntax -- little nits to be aware of
Why do you want to parse strings which describe versions? So one can look at a repository of artefacts and select the best for the user automatically. Each user has a different view of best, some want latest (nightly/snapshot), some want latest release only. Having a repository with automated tools that require humans to understand the contents kinda breaks the automation... If you want to impose on anyone how they should version their artifacts? There is zero % of chance for that. No, but by being flexible to a given set of versioning schemes on can. Like I said, we are picking up most of Maven's repository w/o imposing anything, and it also works for other common version standards. regards Adam
Re: URI/URL Syntax -- little nits to be aware of
Adam R. B. Jack wrote: Why do you want to parse strings which describe versions? So one can look at a repository of artefacts and select the best for the user automatically. Each user has a different view of best, some want latest (nightly/snapshot), some want latest release only. Having a repository with automated tools that require humans to understand the contents kinda breaks the automation... Not necesserly the fact that version number is not parsable by machines determines that fact that versions are uncomparable. In Maven world in POM we can have tags like:: versions version idb1/id name1.0-b1/name tagMAVEN_1_0_B1/tag /version version idb2/id name1.0-b2/name tagMAVEN_1_0_B2/tag /version version idb3/id namebuild-455/name tagMAVEN_1_0_B2/tag /version ... /versions We also have a place for branches there. Using such meta data you can theoretically tell that version 1.0-b1 was released before 1.0-b2 and 1.0-b2 was out before build-445. Any tool can inject such helper artifacts to repository and use them. I am not saying that what we did in Maven in this field is a world championship, but there are some ideas which can be explored and this shows that some things are probably possible. Simply metdata atached to artifacts (which can be denoted as URL) is not sufficient for making smart tools and never be. Artifact versioning is horribly complicated topic and I am simply afraid that attempts to e.g. guess version precedence from version strings are not relaiable in the best case. Michal Michal
Manage discussions to a conclusion...
I am trying to move contentious topics to the Wiki so we can reference them individually, and (over time) come to an agreement. How does this layout work for folks? I have started with one discussion topic: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/ToDo If we can agree upon something like this we can mature it to allow counter proposals, and such. Thoughts? regards, Adam -- Experience Sybase Technology... http://www.try.sybase.com
Re: Processing Versions
[...] and repository possibly won't be limited to project hosted at ASF. This is why we need the Wiki, the e-mail archives are too hard to comsume. It was agreed a while ago that this is for Apache software, we aren't trying to solve this problem for everybody else. We need to stop going back over closed discussions to make simple progress. regards Adam
index.html (was Comments on URI Syntax
http://repo.apache.org/apache/commons-logging/1.0.3/index.html Clearly, this is only useful to users browsing the repository, and therefore makes no sense to include the version information. On index.html, wouldn't we discourage the use of this? Wouldn't we want the HTTP server to do a directory listing, so publishers wouldn't have to update it every time? Also, if we are to allow/support automatic remote publishing, not having to lock/update an index.html would be a bonus. Parsing HTML (simple or fancy) to find links that are children is pretty trivial, so it probably wouldn't matter (to clients who are going to have to do this anyway) but it probably matters to publishers. regards Adam
Disagreements/Agreements
I am almost sure that with WIKI we will have much more chaos. Wiki it's not a perfect techonology for maitaing disussions. -1 for using WIKI for dissusion I didn't mean solely, I think we need a mixture of both. I think e-mail threads are good (when tight) but a thread might end with the passionate folks in disagreement. Those I think we move to the Wiki for voting: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/ToDo We need to record our votes, some simple pros/cons, and at a suitable point close the issue and move it to /Decisions. +1 for using WIKI for writing down the things which were agreed. We need this most certainly: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Decisions I am scouring the mails to this list to look for things I believe are agreed upon decisions. I'll most the non-controversial ones here. [If I make a mistake we can complete discussions on those aspects.] regards Adam
Where to put Version in the URISyntax
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 con's summarized. R, Nick smime.p7s Description: S/MIME Cryptographic Signature
RE: Processing Versions
-Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 5:11 PM To: [EMAIL PROTECTED] Subject: Re: Processing Versions [...] and repository possibly won't be limited to project hosted at ASF. This is why we need the Wiki, the e-mail archives are too hard to comsume. It was agreed a while ago that this is for Apache software, we aren't trying to solve this problem for everybody else. We need to stop going back over closed discussions to make simple progress. 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 which was made and all the limitation which were considered. (temporary in that sense that anything is not written on the stone) So I don't see anything which mentions that artifacts produced outside ASF will be not hosted in ASF repository. It's just NO to no kosher artifacts (in sense of license) in that repository. So it will be our problem if we would like to consider any constrains for version names (which IMHO are no realistic in short term (if ever) even inside ASF) . That's why I strongly believe that any discussion about artifact versioning simply should not take place. And we should assume that version = pchar* Michal
Re: Processing Versions
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 which was made and all the limitation which were considered. (temporary in that sense that anything is not written on the stone) Those are just my assertions. No one has objected so I suppose they are still the Requirements. smime.p7s Description: S/MIME Cryptographic Signature
