Re: URI syntax
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 simply io. On problem is the word project is very overloaded. At apache Jakarta is a Project. a TLP but still a project. By using the term product, we are specifying that is a THING that we are shipping,to us, (the repo list) a product, is a thing that is versioned and distributed. So I am -0 on using the word project. R, Nick
Re: URI syntax
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 while Commons IO may choose to call their project simply io. On problem is the word project is very overloaded. At apache Jakarta is a Project. a TLP but still a project. By using the term product, we are specifying that is a THING that we are shipping,to us, (the repo list) a product, is a thing that is versioned and distributed. So I am -0 on using the word project. R, Nick
RE: [proposal] URI Syntax - v0.2
I changed organisation to name-segments to support structures using reverse-FQDNs e.g: http://repo.apache.org/org/apache http://repo.apache.org/org/tigris http://repo.apache.org/com/sun while maintaining support for single segment organisation names e.g: http://repo.apache.org/oracle See the comments regarding groupId in the original proposal for background: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]ms gNo=308 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 product-specifier and what is part of the version-specifier. However, I don't think this is unreasonable. There is no requirement that tools be able to parse URIs to extract meta-data. -Tim From: Anou Manavalan [mailto:[EMAIL PROTECTED] Tim, This is very nicely laid out. I have one little suggestion, In the Product Specifier, can the organization be made as just name-segment ? This avoids the confusion of / separator that separates the main things like the orgainization / project with / separating the organisation itself. I mean, replace . By - instead of / - since / is used as the main separation. Instead of this, where it is hard to say where the org ends and where the project starts, you sure can differentiate it, but http://repo.apache.org/org/apache/commons-logging this makes more sense as org / project http://repo.apache.org/org-apache/commons-logging regards, -Anou From: Tim Anderson [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [proposal] URI Syntax - v0.2 Date: Fri, 14 Nov 2003 16:39:06 +1100 This version replaces v1.0: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] ache.orgms gNo=308 Overview The key aims of this proposal are: . language and artifact neutrality. It should be possible to support multiple languages and their artifacts, not just java. . it should be possible for users to easily navigate the repository and locate artifacts, including jars and release distributions. Compare this with the existing approach of separating release distributions (http://www.apache.org/dist/) and jars (http://www.ibiblio.org/maven). . it should be possible for tools to construct a URI to locate an artifact using a set of known criteria Artifacts - All files in the repository are artifacts. There is no distinction between artifacts and meta-data. Any relationships between artifacts is determined by supporting tools. Repository URI Components = An absolute repository URI is written as follows: repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier Access specifier The access specifier determines the scheme, authority, and optional repository directory prefix. There is currently no requirement for ftp, scp or file based access - only http is supported: access-specifier = http-access-specifier http-access-specifier = http://; authority / [directory /] directory = path_segments (authority and path_segments are per http://www.ietf.org/rfc/rfc2396.txt) directory is used when the repository cannot be located at the root of an absolute URI. URI examples: http://repo.apache.org/ http://repo.apache.org/pub/repository Product specifier - The product specifier specifies the organisation and project: product-specifier = organisation / project organisation = name-segments project = name-segment name-segments = name-segment *( / name_segment) name-segment = nchar+ nchar = alphanum | escaped | _ | - | ! | ~ | @ | (alphanum and escaped are per http://www.ietf.org/rfc/rfc2396.txt) organisation is the organisation name. It is arbitrary, but should be globally unique. It could be the domain name, or reverse domain name, with . replaced by /, e.g: sun/com, org/apache or simply the name of the organisation, e.g oracle. project is the project name. It is unique within an organisation. E.g, ldap, jndi, maven, commons-logging. URI examples: http://repo.apache.org/org/apache/commons-logging http://repo.apache.org/sun/jndi Version specifier - The version specifier specifies the version of the project: version-specifier = name-segments For the purposes of this proposal, version-specifier is opaque - its format is determined by language and deployment best practices. Some possible examples include: 1.0, v0.9-beta, nightly/20031113, latest, release/1.5.4 URI examples: http://repo.apache.org/apache/commons-logging/1.0 http://repo.apache.org/apache/commons-logging/1.1 http
Re: [proposal] URI Syntax - v0.2
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 product-specifier and what is part of the version-specifier. However, I don't think this is unreasonable. There is no requirement that tools be able to parse URIs to extract meta-data. -Tim I think 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 many of the parts. R, Nick smime.p7s Description: S/MIME Cryptographic Signature
RE: [proposal] URI Syntax - v0.2
From: Nick Chalko [mailto:[EMAIL PROTECTED] 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 product-specifier and what is part of the version-specifier. However, I don't think this is unreasonable. There is no requirement that tools be able to parse URIs to extract meta-data. -Tim I think 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 many of the parts. R, Nick For tools, I think the main objective should be coming up with a set of rules which enable them to unambigously locate an artifact given a set of inputs. I believe this is possible with the two proposals so far, at least for java artifacts. -Tim
Re: [proposal] URI Syntax - v0.2
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 many of the parts. R, Nick For tools, I think the main objective should be coming up with a set of rules which enable them to unambigously locate an artifact given a set of inputs. I believe this is possible with the two proposals so far, at least for java artifacts. I think I see, A tool only needs to be able to generate a URL given the org, project, version, and artifact name. No need to be able to parse a given URL back into it parts. I think I can live with that. -Tim smime.p7s Description: S/MIME Cryptographic Signature
RE: [proposal] URI Syntax - v0.2
However, I don't think this is unreasonable. There is no requirement that tools be able to parse URIs to extract meta-data. There is a requirement that repositories work (at some minimum level) without metadata, especially since we aren't specifying metadata. Without a parsable URI (or parsable URL) how do tools read a repository to do things like clean oldest nightly/snapshot, but leave all releases, download latest release or even the basics determine/display contents, show basic contents (irrespective of version/type). Adam, and how is said tool going to start in the first place? Without meta-data, there is a limit to what the tool can do. Basically, it would have to operate relative to the URL provided to it. As for the particular examples you gave, those carry semantic meaning that would require more specification that is contained in the URI syntax. Although those would be desirable, I don't know that we want to including that kind of semantic specification in the URI. If we are proposing a standard, there has to be a valid purpose for it -- and having a standard that isn't structured for computer processing seems setting the bar pointlessly low. Tim's URI schema supports your operations when combined with with a semantic layer, which can be implied or meta-data based. For me, the strongest argument for tooling (other purely than saving admins effort) is download + verify (MD5/whatever). That does not require the kind of semantic your earlier operations require. The verification content can be relative to the URI provided to the tool. --- Noel
Re: [proposal] URI Syntax - v0.2
Noel wrote: Adam, and how is said tool going to start in the first place? Without meta-data, there is a limit to what the tool can do. Basically, it would have to operate relative to the URL provided to it. My input here is primarily based on writting Ruper (http://www.krysalis.org/ruper), a tool that attempts exactly what I said. It is given links to repositories (local or remote), it read the repositories and allows queries into that repository based on attributes of the resources. It does this by parsing the URLs. You don't have to like the tool, I'm not trying to push the implementation, I'm just giving you experiences from that tool. It allows you to query what is there, query and capture oldest resources [and do a delete/clean], and download newest, etc. Some find such a tool useful, I'd like to believe that apache users (admins and external users) would find it useful. I don't care whose implementation gets used, I feel that these capabilities are so powerful that they ought consist of a minimum bar for apache. Sure, it isn't going to be a 100% generic tool for all cases, but apache is doing this for apache. Let the tools lead and the users (our own committers) can chose to follow. Once, along came a browser and sooner or later folks were converting their documents to HTML 'cos the benefits outweighed the resistence to change. I'm saying that we can't enforce things, but if we make the benefits sufficiently worthwhile transition easy folks then most folks will follow. Again, this tool works today on over 95% of the contents of the Maven repository without any spec. We could achieve this. A nice simple IDE plugin can update a project and download files with or w/o user intervention, e.g. http://www.krysalis.org/ruper/eclipse/index.html. Tim's URI schema supports your operations when combined with with a semantic layer, which can be implied or meta-data based. Aren't you saying that metadata can allow a remote tool to instrospect? Yes, I agree, this has nothing to do with an unparsable URI scheme. The URI scheme is generally fine, but if we aren't addressing metadata (almost impossible) why set back tools that mine metadta from URIs? It works today, why would we force a step backwards? [I sometimes feel the acadaemics of the URI Scheme Specifiecation are outweighing the practicalities of an implementation. I beleive in writting a specification first, but specifications get revised based upon real world experience. Tools are that experience.] For me, the strongest argument for tooling (other purely than saving admins effort) is download + verify (MD5/whatever). That does not require the kind of semantic your earlier operations require. The verification content can be relative to the URI provided to the tool. True, my bad, I go carried away with my argument, the tool I am familiar with, and my own dislike of stale software links. You could have the client tool be told the resource/URI by the user, and do the download/verification, yes. That said, I don't think it buys the user enough, they have to browse/locate stash the URI in some local config. I'd like to say go get me xerces from any repository it is in, but get me the latest, but I only want release not nightly/snapshot (e.g. http://www.krysalis.org/ruper/ant/reposync.htm). That to me, is useful. I don't mind being alone in my views, but I ask again -- if we don't set the bar higher than a one-way URI for download, why write a spec at all? I feel we have the potential to win big, and I'd like the ASF Repository to be a step forward towards these goals, not a step backward. regards Adam
RE: [proposal] URI Syntax - v0.2
From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] snip/ You could have the client tool be told the resource/URI by the user, and do the download/verification, yes. That said, I don't think it buys the user enough, they have to browse/locate stash the URI in some local config. I'd like to say go get me xerces from any repository it is in, but get me the latest, but I only want release not nightly/snapshot (e.g. http://www.krysalis.org/ruper/ant/reposync.htm). That to me, is useful. I don't mind being alone in my views, but I ask again -- if we don't set the bar higher than a one-way URI for download, why write a spec at all? I feel we have the potential to win big, and I'd like the ASF Repository to be a step forward towards these goals, not a step backward. I believe this is possible using the current proposals. If tools follow these when deploying artifacts, a user can can say go get me the latest formal xerces build. That said, some configuration will always be required, whether it be like maven's project.xml dependency resolution, or some other scheme. The proposals aim to avoid users explicitly using URIs. Users should be able to supply a set of criteria and the tools be responsible for constructing the URI. -Tim
RE: [proposal] URI Syntax - v0.2
My input here is primarily based on writting Ruper You don't have to like the tool, I'm not trying to push the implementation I've never even seen the thing, and you are a priori assuming that I don't like it? It allows you to query what is there, query and capture oldest resources [and do a delete/clean], and download newest, etc. How does it know what OLDEST means? I see that Tim is trying to add some more structure, so maybe he's thinking that we can restrict the URI space so that a restricted notion of version assures an automatable concept of succession. Some find such a tool useful, I'd like to believe that apache users (admins and external users) would find it useful. I don't disagree. I simply said that if you view the repository solution as a layer of specifications, the lowest layer can be a syntax that does not require semantics such as an automatable concept of succession. If we need that, we can add it either by a convention within the URI space, or by other means. [I sometimes feel the acadaemics of the URI Scheme Specifiecation are outweighing the practicalities of an implementation. I beleive in writting a specification first, but specifications get revised based upon real world experience. Tools are that experience.] I'd like to say go get me xerces from any repository it is in, but get me the latest, but I only want release not nightly/snapshot That to me, is useful. Absolutely. But that may require something more than the URI schema. :-) I feel we have the potential to win big, and I'd like the ASF Repository to be a step forward towards these goals, not a step backward. I agree. But one layer at a time. :-) --- Noel
RE: [proposal] URI Syntax - v0.2
From: Noel J. Bergman [mailto:[EMAIL PROTECTED] My input here is primarily based on writting Ruper You don't have to like the tool, I'm not trying to push the implementation I've never even seen the thing, and you are a priori assuming that I don't like it? It allows you to query what is there, query and capture oldest resources [and do a delete/clean], and download newest, etc. How does it know what OLDEST means? I see that Tim is trying to add some more structure, so maybe he's thinking that we can restrict the URI space so that a restricted notion of version assures an automatable concept of succession. The common build version specifier proposal does add structure to the version, but doesn't enable tools to determine if one version is older or newer than another. A tool could reasonably assume that version 1.0 2.0 but this is only valid for projects which follow numeric versions. For those projects which love codename versions (e.g, chicago, delta), no assumptions can be made. -Tim
Parsable URI (Re: [proposal] URI Syntax - v0.2)
Noel wrote: You don't have to like the tool, I'm not trying to push the implementation I've never even seen the thing, and you are a priori assuming that I don't like it? No Neol, I'm not that emoition, I meant it dispassionately and without inference, maybe it just read differently. That was more 'one' doesn't have to like it. [I know this list has (in the past) slipped into implementation codebase factions, and I was hoping not to encourage that.] So perhaps I should've writen ... One doesn't have to like this tool/implementation, but the results are valuable at layer 1. It allows you to query what is there, query and capture oldest resources [and do a delete/clean], and download newest, etc. How does it know what OLDEST means? I see that Tim is trying to add some more structure, so maybe he's thinking that we can restrict the URI space so that a restricted notion of version assures an automatable concept of succession. Ruper parses all the attributes of the resources, including the version, and either do (pchar) string comparisons or (in versions case) structured comparisons. Much as there are a few different flavours of a versions they pretty much fall into a parsable pattern. Ruper (through Version) strictly parses the string in a number of different ways (known formats) until one matches. Again, the most important aspect of parsing the URI is knowing what is separated from what, that this pchar is a version, this pchar is a type (or whatever). If values can by groked within that, great, if not, it is still Some find such a tool useful, I'd like to believe that apache users (admins and external users) would find it useful. I don't disagree. I simply said that if you view the repository solution as a layer of specifications, the lowest layer can be a syntax that does not require semantics such as an automatable concept of succession. If we need that, we can add it either by a convention within the URI space, or by other means. We all agree to layers, but I am testing what are the minimum things we'll accept for layter one. I beleive that the repository needs to be 'tooling readable', hence the URI needs to be parse, the other aspects (can an attributed be fully groked) can come later. Again, I need to get to the wiki to put a proposal and pros/cons, I'll try next week. Absolutely. But that may require something more than the URI schema. :-) But if it doesn't have to, should it? I'm trying to determine what we ought will accept at the lowest level. I think clean up is important, I like the other aspects. I agree that much should be done via metadata (e.g. dependencies) however writting potentially shared/conflicting files to a repository is a scary step, and I'd like to see how much we can do with atomic artefacts. I feel we have the potential to win big, and I'd like the ASF Repository to be a step forward towards these goals, not a step backward. I agree. But one layer at a time. :-) Yes, and we are doing layer one -- without metadata, we still need to determine our minimum expectations. If URI is this contentious/involved, I could see metadata as being a long drawn out process one we don't agree on as a whole. Maybe this first layer is the hardest, but I'd like it to be the one giving the most rewards so we aren't all sitting waiting for metadata. regards, Adam
RE: Parsable URI (Re: [proposal] URI Syntax - v0.2)
The URI proposals so far specify URIs which are just as parseable as those currently in use by maven's repository [1]. The only caveat is that they need to be parsed from right to left, as the organisation [2] part of product-specifier cannot be separated from the directory part of access-specifier, without prior knowledge of the repository structure. E.g: if a repository has its root at: http://www.apache.org/repository And the organisation of a project is: org/apache And the project name is: commons-cli The URI: http://www.apache.org/repository/org/apache/commons-cli needs to be parsed from right to left to determine that the project is commons-cli. Without knowing that the repository has its root at: http://www.apache.org/repository; the organisation cannot be determined. Like maven's repository, which doesn't impose any version naming convention, tools trying to parse the URI need to make guesses as to which version is older or newer. -Tim [1] http://www.ibiblio.org/maven [2] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Noel wrote: You don't have to like the tool, I'm not trying to push the implementation I've never even seen the thing, and you are a priori assuming that I don't like it? No Neol, I'm not that emoition, I meant it dispassionately and without inference, maybe it just read differently. That was more 'one' doesn't have to like it. [I know this list has (in the past) slipped into implementation codebase factions, and I was hoping not to encourage that.] So perhaps I should've writen ... One doesn't have to like this tool/implementation, but the results are valuable at layer 1. It allows you to query what is there, query and capture oldest resources [and do a delete/clean], and download newest, etc. How does it know what OLDEST means? I see that Tim is trying to add some more structure, so maybe he's thinking that we can restrict the URI space so that a restricted notion of version assures an automatable concept of succession. Ruper parses all the attributes of the resources, including the version, and either do (pchar) string comparisons or (in versions case) structured comparisons. Much as there are a few different flavours of a versions they pretty much fall into a parsable pattern. Ruper (through Version) strictly parses the string in a number of different ways (known formats) until one matches. Again, the most important aspect of parsing the URI is knowing what is separated from what, that this pchar is a version, this pchar is a type (or whatever). If values can by groked within that, great, if not, it is still Some find such a tool useful, I'd like to believe that apache users (admins and external users) would find it useful. I don't disagree. I simply said that if you view the repository solution as a layer of specifications, the lowest layer can be a syntax that does not require semantics such as an automatable concept of succession. If we need that, we can add it either by a convention within the URI space, or by other means. We all agree to layers, but I am testing what are the minimum things we'll accept for layter one. I beleive that the repository needs to be 'tooling readable', hence the URI needs to be parse, the other aspects (can an attributed be fully groked) can come later. Again, I need to get to the wiki to put a proposal and pros/cons, I'll try next week. Absolutely. But that may require something more than the URI schema. :-) But if it doesn't have to, should it? I'm trying to determine what we ought will accept at the lowest level. I think clean up is important, I like the other aspects. I agree that much should be done via metadata (e.g. dependencies) however writting potentially shared/conflicting files to a repository is a scary step, and I'd like to see how much we can do with atomic artefacts. I feel we have the potential to win big, and I'd like the ASF Repository to be a step forward towards these goals, not a step backward. I agree. But one layer at a time. :-) Yes, and we are doing layer one -- without metadata, we still need to determine our minimum expectations. If URI is this contentious/involved, I could see metadata as being a long drawn out process one we don't agree on as a whole. Maybe this first layer is the hardest, but I'd like it to be the one giving the most rewards so we aren't all sitting waiting for metadata. regards, Adam
RE: [VOTE] Where is version in URI Syntax
I've restructured the wiki page at http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/WhereIsVersionInU RISytnax, and removed the part about symbolic links. -Tim -Original Message- From: Nick Chalko [mailto:[EMAIL PROTECTED] Sent: Friday, 14 November 2003 11:00 AM To: [EMAIL PROTECTED] Subject: Re: [VOTE] Where is version in UIR Syntax Tim Anderson wrote: I have a few comments on the content of that page: 1. Not sure why the discussion and the proposals are separate, given the partial duplication of pros and cons for each. Would prefer to see these merged. Good point, feel free to merge them. and add your pro cons. We will need this for later, when people ask us Why, we can point them to the wiki summary. 2. Version be a mandatory component of artifact filename Pros: . Artifacts become identifiable when *downloaded* from the repository. . This is not compatible with the current ASF scheme. Neither maven, nor dist require version in the artifact filename. Cons: . Presumes to know requirements of other repository users, for which we have no requirements. 3. Version in directory Cons: . I don't see how the need for a 'latest' symbolic link is a con. There is no uniform way at ASF at the moment to indicate the latest version. . Scheme not currently used by ASF. 4. There has been no discussion on how to cope with nightly or snapshot builds, which could change the version syntax. E.g: 1. Subdir per build: http://repo.apache.org/apache/commons-cli/nightly/20031112/... http://repo.apache.org/apache/commons-cli/nightly/20031113/... 2. Embedded in version: http://repo.apache.org/apache/commons-cli/nightly-20031112/... http://repo.apache.org/apache/commons-cli/nightly-20031113/... I'm leaning towards the former, as browsing is simpler. OTOH, 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, 14 November 2003 9:51 AM To: [EMAIL PROTECTED] Subject: Re: [VOTE] Where is version in UIR Syntax 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/WhereIs VersionInURISytnax 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 URISyntax. R, Nick
URI Syntax: nightly and release builds
The URISyntax proposal is silent on how to handle nightly, release, snapshot, and latest builds. This should be formalised. The current proposal has: product-specifier = organisation / project / version where: version = *pchar To support nightlies etc, this leads to the possibility of artifacts named: http://repo.apache.org/apache/commons-cli/1.0/... http://repo.apache.org/apache/commons-cli/1.1/... http://repo.apache.org/apache/commons-cli/latest/... - link to ../1.1 http://repo.apache.org/apache/commons-cli/nightly-20031112/... http://repo.apache.org/apache/commons-cli/nightly-20031113/... http://repo.apache.org/apache/commons-cli/nightly-latest/... - link to ../nightly-latest Where *latest is a symlink to the latest version, to aid navigation. Option 1. Specify version format To formalise the above, product-specifier could be changed to: product-specifier = organisation / project / [rtype -] version rtype = nightly | snapshot version = latest | MMDD [- HHMM [SS]] | *pchar Cons: . clutters the repository . doesn't follow existing conventions, e.g: http://cvs.apache.org/builds/jakarta-commons/nightly/commons-cli/ . no facility to indicate snapshots or nightlies of a particular version, if two or more versions are being developed concurrently. Option 2. Add build directory - To reduce clutter, a new directory could be introduced to separate releases from nightly and snapshot builds i.e: product-specifier = organisation / project / rtype / version rtype = release | nightly | snapshot version = latest | MMDD [- HHMM [SS]] | *pchar E.g: http://repo.apache.org/apache/commons-cli/release/l.0/... http://repo.apache.org/apache/commons-cli/release/l.1/... http://repo.apache.org/apache/commons-cli/release/latest/... - symlink to ../1.1 http://repo.apache.org/apache/commons-cli/nightly/20031112/... http://repo.apache.org/apache/commons-cli/nightly/20031113/... - symlink to ../20031113 http://repo.apache.org/apache/commons-cli/snapshot/20030901-1032/... http://repo.apache.org/apache/commons-cli/snapshot/latest/... - symlink to ../20030901-1032 Cons: . no facility to indicate snapshots or nightlies of a particular version, if two or more versions are being developed concurrently. Option 3. Concurrent version nightly/snapshot builds To allow nightlies and snapshots of multiple versions, product-specifier could be changed to: product-specifier = organisation / project / build build = release-build | interim-build release-build = release / version interim-build = itype / version / MMDD [- HHMM [SS]] itype = nightly | snapshot version = latest | *pchar E.g: http://repo.apache.org/apache/commons-cli/release/l.0/... http://repo.apache.org/apache/commons-cli/release/l.1/... http://repo.apache.org/apache/commons-cli/release/latest/... - symlink to ../1.1 http://repo.apache.org/apache/commons-cli/nightly/1.0/20031112/... http://repo.apache.org/apache/commons-cli/nightly/1.0/20031113/... http://repo.apache.org/apache/commons-cli/nightly/1.0/latest/... - symlink to ../20031113 http://repo.apache.org/apache/commons-cli/nightly/2.0/20031112/... http://repo.apache.org/apache/commons-cli/nightly/2.0/20031113/... http://repo.apache.org/apache/commons-cli/nightly/2.0/latest/... - symlink to ../20031113 http://repo.apache.org/apache/commons-cli/snapshot/1.0/20030901-1032/... http://repo.apache.org/apache/commons-cli/snapshot/1.0/latest/... - symlink to ../20030901-1032 http://repo.apache.org/apache/commons-cli/snapshot/2.0/20031101-1452/... http://repo.apache.org/apache/commons-cli/snapshot/2.0/latest/... - symlink to ../20031101-1452 Option 4. Concurrent version interim builds An alternative to Option 3 would be to remove any distinction from nightly and snapshot builds, as the difference IMO is only cosmetic: product-specifier = organisation / project / build build = release-build | interim-build release-build = release / version interim-build = interim / version / MMDD [- HHMM [SS]] version = latest | *pchar E.g: http://repo.apache.org/apache/commons-cli/release/l.0/... http://repo.apache.org/apache/commons-cli/release/l.1/... http://repo.apache.org/apache/commons-cli/release/latest/... - symlink to ../1.1 http://repo.apache.org/apache/commons-cli/interim/1.0/20031112/... http://repo.apache.org/apache/commons-cli/interim/1.0/20031113/... http://repo.apache.org/apache/commons-cli/interim/1.0/latest/... - symlink to ../20031113 http://repo.apache.org/apache/commons-cli/interim/2.0/20031112/... http://repo.apache.org/apache/commons-cli/interim/2.0/20031113/... http://repo.apache.org/apache/commons-cli/interim/2.0/latest/... - symlink to ../20031113
Re: URI Syntax: nightly and release builds
Tim Anderson wrote: OK - so it should be at part of the java artifact specifier proposal [1], or do you envision another layer? I don't think this is java specific - its software development process specific. My current thinking is that it is a langauge independent layer is sufficient (mainly because I think I have resolved how to do everything I want relative to java based on these two layers). The URI Syntax proposal [2] that the above extends is becoming a little thin. That's fine. It just means we have a simple and specific specification dealing with a simple and specific abstaction. Cheers, Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | ||
Re: [proposal] URI Syntax - v0.2
Digesting each section slowly, Its great idea to make Artifact Specifier to be opaque to give way to different languages, but I am not sure about the Version Specifier. Version Specifier can be considered as language independent and allowing different best practices in there would make the repository unordered and could confuse the users. 1.0, v0.9-beta, nightly/20031113, latest, release/1.5.4 URI examples: http://repo.apache.org/apache/commons-logging/1.0 http://repo.apache.org/xorg/xyz/release/1.2 http://repo.apache.org/yorg/abc/v0.9-beta/abc.. thoughts ? regards, -Anou From: Tim Anderson [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [proposal] URI Syntax - v0.2 Date: Fri, 14 Nov 2003 16:39:06 +1100 This version replaces v1.0: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]ms gNo=308 Overview The key aims of this proposal are: . language and artifact neutrality. It should be possible to support multiple languages and their artifacts, not just java. . it should be possible for users to easily navigate the repository and locate artifacts, including jars and release distributions. Compare this with the existing approach of separating release distributions (http://www.apache.org/dist/) and jars (http://www.ibiblio.org/maven). . it should be possible for tools to construct a URI to locate an artifact using a set of known criteria Artifacts - All files in the repository are artifacts. There is no distinction between artifacts and meta-data. Any relationships between artifacts is determined by supporting tools. Repository URI Components = An absolute repository URI is written as follows: repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier Access specifier The access specifier determines the scheme, authority, and optional repository directory prefix. There is currently no requirement for ftp, scp or file based access - only http is supported: access-specifier = http-access-specifier http-access-specifier = http://; authority / [directory /] directory = path_segments (authority and path_segments are per http://www.ietf.org/rfc/rfc2396.txt) directory is used when the repository cannot be located at the root of an absolute URI. URI examples: http://repo.apache.org/ http://repo.apache.org/pub/repository Product specifier - The product specifier specifies the organisation and project: product-specifier = organisation / project organisation = name-segments project = name-segment name-segments = name-segment *( / name_segment) name-segment = nchar+ nchar = alphanum | escaped | _ | - | ! | ~ | @ | (alphanum and escaped are per http://www.ietf.org/rfc/rfc2396.txt) organisation is the organisation name. It is arbitrary, but should be globally unique. It could be the domain name, or reverse domain name, with . replaced by /, e.g: sun/com, org/apache or simply the name of the organisation, e.g oracle. project is the project name. It is unique within an organisation. E.g, ldap, jndi, maven, commons-logging. URI examples: http://repo.apache.org/org/apache/commons-logging http://repo.apache.org/sun/jndi Version specifier - The version specifier specifies the version of the project: version-specifier = name-segments For the purposes of this proposal, version-specifier is opaque - its format is determined by language and deployment best practices. Some possible examples include: 1.0, v0.9-beta, nightly/20031113, latest, release/1.5.4 URI examples: http://repo.apache.org/apache/commons-logging/1.0 http://repo.apache.org/apache/commons-logging/1.1 http://repo.apache.org/apache/commons-logging/latest http://repo.apache.org/apache/ant/release/1.5.4 http://repo.apache.org/apache/ant/nightly/20031113 http://repo.apache.org/apache/commons-cli/nightly/1.0/20031113 http://repo.apache.org/apache/commons-cli/nightly/2.0/20031113 Artifact specifier -- The artifact specifier uniquely identifies an artifact within a project version: artifact-specifier = name-segments For the purposes of this proposal, artifact-specifier is opaque - its format is determined by language and deployment best practices. Some possible examples include: jars/commons-logging-1.1.jar binaries/linux/httpd-2.0.40-i686-pc-linux-gnu-rh73.tar.gz URI examples: http://repo.apache.org/apache/common-logging/1.1/jars/commons-logging-1.1.ja r http://repo.apache.org/apache/httpd/2.0.48/docs/httpd-docs-2.0.48.en.zip http://repo.apache.org/apache/ant/1.5.4/KEYS Rationale = Of the URI components: . access-specifier and product-specifier are common accross all languages and deployments. . version-specifier is subject to language or deployment best practices . artifact-specifier is subject to language, deployment, artifact, or project best practices It is envisioned
Tooling (was Version Specifier in Re: [proposal] URI Syntax - v0.2)
Its great idea to make Artifact Specifier to be opaque to give way to different languages, but I am not sure about the Version Specifier. Version Specifier can be considered as language independent and allowing different best practices in there would make the repository unordered and could confuse the users. I know of opinions on both sides. Some say we can't dictate, so best practices are the best we can expect even they'll be loose. Others say, we can't achieve conformity unless we try -- and that tools can't process totally unstructured opaque data. I think the questions become (building upon each other): 1) Ought the URI be uniquely (unambiguously) parsable [i.e. things such as your '-' not '/' proposal.] 2) Ought the URI be considered 'metadata' itself structured? 3) Is the goal for the repository to be tools processable [even without metadata]? I'll work something up in the Wiki TODOs section and transfer any pros/cons there. --- One last comment on tools-based verses human-based. We are discussing version in filename so it's version is identifiable once download from the repository. It occurred to me that we are likely assuming a dumb client (a human w/ browser perhaps) in that thought. Nothing is to stop tools downloading an unversioned filename and adding -[version] to the end as it writes it to disk. Since we can likely assume that many humans have bad habits of not doing verification checks of the contents of repositories that they download with a browser, ought we actually weight our cogitations towards tooling that can browse/select/download/verify. Note: I'm not talking implementation, nor any tool, and I'm definitely not saying disallow the human user use case, I'm just saying focus on tooling. IMHO tooling (built upon certain levels of repository consistency) make the repository@ venture more than just a re-organization of file systems, and allow us to scale this and save a lot of wasted human effort. It seems a critical goal to me. Thoughts? regards Adam
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]
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
Re: Comments on URI Syntax
On Sun, 2003-11-09 at 01:41, Tim Anderson wrote: I have a few comments on the proposed URI Syntax, from http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax. quote Compromise URI http://host/project/version/artifact-[version;].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 /quote Having the version in the path certainly doesn't hurt readability and it definitely will make the structure more navigable as it keeps a massive number of artifacts from piling up in one place. And of course you have the by product of faster indexing and quicker hits by the file system and if transfered to another storage mechanism the reduction of the bit per bucket can only be a good thing. Simple ideas are good ones. Good idea! +1 1. This should be written as: http://host/project/version/artifact[-version].ext as the '-' is only required if the version is present. I think the version should always be present. People will use the repository directly and I think that's ok so you if you copy an artifact somewhere by mistake it is always nice to have as much information as possible so making the version optional I don't think is a great idea. 2. Does '.ext' need to be mandatory? I'm assuming that a project is free to deploy whatever it likes into the repository, not all of which should be forced to have extensions (e.g, Unix shell scripts, README files). I don't think they need to be, but I haven't thought about that one much. We have presumed so in Maven because artifacts have generally been archives but there's no reason there has to be an extension. 3. project is too limiting as it is required to be globally unique, resulting in unwieldy names like: jakarta-commons-logging or org.apache.jakarta.commons.logging I would prefer to see this split into: organisation/product where: . organisation is arbitrary, but globally unique. It could be the domain name, e.g sun.com, the reverse domain name e.g org.apache, or simply the name of the organisation, e.g oracle. . project is the project name, unique within the organisation, e.g: jndi, ldap, commons-logging etc. What we've discussed in Maven-land is using something like a groupId which might look like: org.apache.maven and actually split on the dot to make a directory. So basically organization by FQDN. Something which would also make indexing easier in filesystems and I think makes it easier to navigate by a person. 4. artifact is too limiting as it groups all artifacts for one project in a single directory. For projects producing large no.s of artifacts, it becomes difficult for users to browse. The httpd project for example produces multiple binaries, for different platforms (see http://www.apache.org/dist/httpd/) The requirement that -version is prepended to the artifact name also doesn't support language specific requirements. I would prefer to see this split into: [type/][platform/]artifact where: . type is optional and arbitrary, determined by the deployment tool. E.g: jars, binaries, docs etc. . platform is optional and arbitrary, determined by the deployment tool. Having the type I think is good and has worked for Maven. +1 . artifact is determined by the deployment tool, and includes: . the artifact name . the version (optional) . the platform (optional) . the extension (optional) . the type (optional) E.g, -src, -bin etc. This allows the repository to cater for language-specific deployment tools. For java, artifact could be: artifact-name[-version][-type][.ext] E.g: . LICENSE.txt . ant-1.5.1.jar . ant-1.5.1-src.zip For C binaries, artifact could be: artifact-name-version-platform.ext E.g: . httpd-2.0.43-sparc-sun-solaris2.8.tar.gz In summary, I think the URI should be of the form: http://host/organisation/project/version/[type/][platform/]arti fact, For organization I would suggest a groupId where most projects would use their FQDN and split on the dot for directory structure. Also the manditory use of a version in the artifact name as even in your example below the LICENSE.txt could potentially change from one release to another and you wouldn't want to copy one version over another by mistake and distribute it. An Unlikely example yes, but possible if the version is not in the artifact itself. I also think the type should be required. So my attempt for further refinement would be this: http://host/groupId/project/version/type/[platform/]/artifact-version[.ext] with the format of artifact determined by the deployment tool. For example: http://repo.apache.org/apache/ant/1.5.4/LICENSE.txt http
RE: Comments on URI Syntax
Where is Tim's Layout? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc Noel J. Bergman [EMAIL PROTECTED] wrote on 09/11/2003 06:22:51 PM: Jason, I think that Tim's ideas were pretty well-thought out and reflect a workable consensus. The changes you are making to his ideas, if I read the correctly, are to mandate a couple of things that he did not rule out, but permitted to remain optional. Having them as optional does not strike me as a problem. Best practices can always suggest that optional elements be used, and we'll discover in practice how broadly the rule(s) should apply. We should make sure that folks like William Rowe and others who have commented on the repository structure lately take a look at, and provide feedback on, Tim's layout. --- Noel
RE: Comments on URI Syntax
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]ms gNo=266 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, 9 November 2003 7:28 PM To: [EMAIL PROTECTED] Subject: RE: Comments on URI Syntax Where is Tim's Layout? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc Noel J. Bergman [EMAIL PROTECTED] wrote on 09/11/2003 06:22:51 PM: Jason, I think that Tim's ideas were pretty well-thought out and reflect a workable consensus. The changes you are making to his ideas, if I read the correctly, are to mandate a couple of things that he did not rule out, but permitted to remain optional. Having them as optional does not strike me as a problem. Best practices can always suggest that optional elements be used, and we'll discover in practice how broadly the rule(s) should apply. We should make sure that folks like William Rowe and others who have commented on the repository structure lately take a look at, and provide feedback on, Tim's layout. --- Noel
RE: Comments on URI Syntax
On Sun, 2003-11-09 at 02:22, Noel J. Bergman wrote: Jason, I think that Tim's ideas were pretty well-thought out and reflect a workable consensus. The changes you are making to his ideas, if I read the correctly, are to mandate a couple of things that he did not rule out, but permitted to remain optional. Having them as optional does not strike me as a problem. Best practices can always suggest that optional elements be used, and we'll discover in practice how broadly the rule(s) should apply. We should make sure that folks like William Rowe and others who have commented on the repository structure lately take a look at, and provide feedback on, Tim's layout. If someone else wants to act as secretary that's cool but I wanted to try and collect the ideas expressed so far in a small document. I'm not a huge fan of the wiki. If someone else has started some coherent documentation I won't step on anyone's toes but I'll help codify any existing docs there are. --- Noel -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
Re: Comments on URI Syntax
[EMAIL PROTECTED] wrote: 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? Good point! Is not a README a feature of an artifact? Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
RE: Comments on URI Syntax
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. -Tim
Re: Comments on URI Syntax
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. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
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
Nick Chalko wrote: ... 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 * 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://host/project/artifact-type/artifact-[version].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
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. site/project/version/artifact-version.type 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
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 consistency. I can live with it beeing required, if that's what most people think is best. But if this is the case, then we should make it consistent and make sure the projects themself support it. The jar name may be used in many places, and it will be a mess if we end up with multiple names or a wrong version is picked up ( just think about security - what happens if you install a fixed jar but the program uses the old one because that's how it was configured somewhere ) +1 on having an external manifest: /project-version/artifact.jar-MANIFEST And maybe: /project-version/descriptor.xml ( with all the info in gump - if we need more I think we should update the gump descriptors ) There are already tools to process the MANIFEST, and a signed jar can be verified automatically. It is possible to include a lot of extra headers in the manifest ( like copyright/license, etc). Costin
