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:: b1 1.0-b1 MAVEN_1_0_B1 b2 1.0-b2 MAVEN_1_0_B2 b3 build-455 MAVEN_1_0_B2 ... 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
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
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 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: URI/URL Syntax -- little nits to be aware of
> 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. -Tim PS - is anyone else having problems with this list? I never received my original response to this.
Re: URI/URL Syntax -- little nits to be aware of
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. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
RE: URI/URL Syntax -- little nits to be aware of
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] > > I know URI syntax is dragging on (and I don't know if we are coming to > consensus or going round and round) but I hope folks are still > open eared to > this stuff, because IMHO the URI /URL syntax may be *the only critical > thing* we need to determine/document for repository to be at a > satisfactory > phase 1. > > As I believe Roy wrote -- we must include computer parsability into the > specification. I feel the URI and the resource/file names need to > be machine > parsable so the directories/HTML are metadata in themselves for > simple/smart > tools. > > 2) Version in the filename has it's issues also -- e.g. > "jakarta-servlet-api-4-1.1" -- is that version 4 or 1? (It is 1.1 of > jakarta-servlet-api-4.) > 3) Some folks like to use _ not - for such separators. Some also > like to use > periods in resource names. Both make resource parsing hard. Having the version in the directory path helps here. > > If we wish to parse we either need some convention or separator -- or we > need to better define the version namespace. Also, whether > version is in the > filename or the directory, how does one 'understand' the version? Is > 1.1-SNAPSHOT, "better" than 1.1, "better" than "-alpha"? If we want to > process versions we certainly need some sort of specification. [Note: > metadata in each group could define the version specification/standard, > etc.] I believe thats outside the scope. > > BTW: With code specifically trying to "sniff out the right stuff" > Ruper2 is > currently able to process all but 35 of the couple of thousand of > artefacts > on Maven's Ibiblio repository. Those 35 have resource name formats that > break parsing. Maybe we do an 80/20 rule, but it seems a real shame not to > have 100%. > > BTW: The same parsing issues arise for anything at the end of the > filename, > e.g. -src or -docs. How does one know those aren't some version attribute > (like -snapshot or -beta). Again, having the version in the directory path helps here. > > I don't know what folks views are, but I could see we have to break every > part of the URI down and define/document "best practices" or "standard" in > order to ensure the URIs were parsable. A such, I believe we > ought document > a URI and URL specification (on Wiki would be my preference, but if nobody > else volunteers to be secretary, I'd take that one.) I do feel > strongly that > the syntax must be completely computer readable w/o additional > metadata (at > least most of the time.) +1. But bear in mind that these "best practices" will be language specific. > Also, to provide benefit to the users we probably need > abstractions such as > "latest", or groupings such as "all artefacts". Do we work those > into a URI? > Into a URL? > > Making a user come get the "jars" and then come get the "src" or "xml > resources" (if there are such things) seems rude. A user ought be able to > say type="all", and get all of them. My experience has been that grouping > those in one directory is probably easiest for the clients (since > they don't > need metadata to make associations.) Not necessary I think, as tools can provide support for this. If necessary, it could be done via symlinks. > As such, this pushes one towards one > directory per group w/ all versions/types in there -- so long as the > filename is parsable. [I won't lie to you, I don't know what the right > solution is, sometimes separating is good, sometimes together is good. I > lean towards the latter.] -1. I see the repository as providing support for: 1. end users downloading the latest distributions of projects 2. tools accessing artifact dependencies. Lumping everything in one directory doesn't make it easier for [1]. See http://www.apache.org/dist/httpd/binaries/ for an example. > > Finally, I suspect there will be "other stuff" (other URLs) within a > repository that do not revert to a resource URI (e.g. metadata files). I > suspect we have to be able to programmatically exclude those without > metadata. (e.g. dot files or all files ending with .xml are excluded, or > ... ) 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
RE: URI/URL Syntax -- little nits to be aware of
> 1) I have angst over the version in the URI (as a 'directory') > only because > of the likely need for symbolic links for 'latest'. I think this > is a burden > on publishing tools, and leads to errors (what if two tool were publishing > at same time, can symbolic links be created remotely, etc.) That > said, read > on... I am also -1 for separate directories per version > 2) Version in the filename has it's issues also -- e.g. > "jakarta-servlet-api-4-1.1" -- is that version 4 or 1? (It is 1.1 of > jakarta-servlet-api-4.) > 3) Some folks like to use _ not - for such separators. Some also > like to use > periods in resource names. Both make resource parsing hard. > Why do you want to parse strings which describe versions? If you want to impose on anyone how they should version their artifacts? There is zero % of chance for that. Version can be anything like: build-994 or 1.2.alpha-5 or 4-1.1 and we should just decide where string which describe a version is included in the URL and stop there. Michal
