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
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
[proposal] common build version specifier - v0.1
Overview This proposal extends the URI Syntax proposal, v0.2: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]ms gNo=367 The key aims of this proposal are to: . formalise version-specifier for projects which provide formal and interim builds; . provide a set of best practices for such projects; and . enable tools to construct a URI to unambigously locate a particular project version using a set of known criteria URI Components == An absolute repository URI is written as follows: repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier This proposal defines version-specifier as follows: version-specifier = build build = formal-build | interim-build formal-build = [formal-build-designation /] version interim-build = interim-build-designation / version [ / interim-version ] interim-version = latest | MMDD [- HHMM [SS]] formal-build-designation = release | ... interim-build-designation = interim | nightly | snapshot | ... version = latest | *pchar (pchar is per http://www.ietf.org/rfc/rfc2396.txt) Build - Builds are separated into formal and interim builds. A formal build may be a final or milestone release. e.g: 1.0, release/1.0, 1.0-beta1, release/1.0-rc1 An interim build is an informal release, produced by a nightly build or an ad-hoc snapshot. e.g: nightly/1.0/20031113, snapshot/1.2beta1. Version --- Version is either latest or arbitrary, determined by the project or deployment tool. latest always refers to the latest version of a particular build, and may be supported using symbolic links, or via http redirection. 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 Interim version --- The interim version is either a timestamp, or latest. latest always refers to the latest interim version and may be supported using symbolic links, or via http redirection. 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 Rationale = Optional build designation for formal builds formal-build is defined as: formal-build = [formal-build-designation /] version formal-build-designation = release | ... The formal-build-designation is optional for those projects which don't produce interim builds, or don't wish to add another directory for formal releases. E.g: http://repo.apache.org/apache/commons-cli/l.0/... http://repo.apache.org/apache/commons-cli/l.1/... Mandatory version in interim builds --- interim-build is defined as: interim-build = interim-build-designation / version [ / interim-version ] interim-version = latest | MMDD [- HHMM [SS]] This enables support for multiple versions of builds, if there are two or more concurrent development streams. E.g, to support nightly builds of versions 1.0 and 2.0 of commons-cli: 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 Build designation naming conventions formal-build-designation and interim-build-designation are defined as: formal-build-designation = release | ... interim-build-designation = interim | nightly | snapshot | ... In other words, tools may use release, interim etc, but may also extend them to define their own. Tool support Tools can unambigously locate a project version given the following criteria: . formal or interim build-designation Optional. If not specified, assume formal build. . version Mandatory. . interim-version Optional. If specified, build designation must also be specified. Example 1. -- Given: organisation = apache project = commons-cli version = 1.0 build-designation = interim-version = The URI would be: http://repo.apache.org/apache/commons-cli/1.0 Example 2. -- Given: organisation = apache project = commons-cli version = latest build-designation = interim-version = The URI would be: http://repo.apache.org/apache/commons-cli/latest If two versions of commons-cli are available, 1.0 and 1.1, the URI would resolve to: http://repo.apache.org/apache/commons-cli/1.1
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] common build version specifier - v0.1
Tim, I *love* your specifications, I really appreciate the clear/concise/explicit nature of them. I only wish you'd use Wiki not EyeBrowse as your persistent documentation tool. Wiki has versioning (so we can see older copies should we need to refer back) and such, and allows other to make (respectful) changes, and allows a view not cluttered throughout mail threads. I'm game to be your cut-n-paste-wallah if you really need one, but please (at least) refer to your proposals in the Wiki. regards Adam - Original Message - From: Tim Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 14, 2003 8:21 PM Subject: [proposal] common build version specifier - v0.1 Overview This proposal extends the URI Syntax proposal, v0.2: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]ms gNo=367 The key aims of this proposal are to: . formalise version-specifier for projects which provide formal and interim builds; . provide a set of best practices for such projects; and . enable tools to construct a URI to unambigously locate a particular project version using a set of known criteria URI Components == An absolute repository URI is written as follows: repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier This proposal defines version-specifier as follows: version-specifier = build build = formal-build | interim-build formal-build = [formal-build-designation /] version interim-build = interim-build-designation / version [ / interim-version ] interim-version = latest | MMDD [- HHMM [SS]] formal-build-designation = release | ... interim-build-designation = interim | nightly | snapshot | ... version = latest | *pchar (pchar is per http://www.ietf.org/rfc/rfc2396.txt) Build - Builds are separated into formal and interim builds. A formal build may be a final or milestone release. e.g: 1.0, release/1.0, 1.0-beta1, release/1.0-rc1 An interim build is an informal release, produced by a nightly build or an ad-hoc snapshot. e.g: nightly/1.0/20031113, snapshot/1.2beta1. Version --- Version is either latest or arbitrary, determined by the project or deployment tool. latest always refers to the latest version of a particular build, and may be supported using symbolic links, or via http redirection. 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 Interim version --- The interim version is either a timestamp, or latest. latest always refers to the latest interim version and may be supported using symbolic links, or via http redirection. 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 Rationale = Optional build designation for formal builds formal-build is defined as: formal-build = [formal-build-designation /] version formal-build-designation = release | ... The formal-build-designation is optional for those projects which don't produce interim builds, or don't wish to add another directory for formal releases. E.g: http://repo.apache.org/apache/commons-cli/l.0/... http://repo.apache.org/apache/commons-cli/l.1/... Mandatory version in interim builds --- interim-build is defined as: interim-build = interim-build-designation / version [ / interim-version ] interim-version = latest | MMDD [- HHMM [SS]] This enables support for multiple versions of builds, if there are two or more concurrent development streams. E.g, to support nightly builds of versions 1.0 and 2.0 of commons-cli: 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 Build designation naming conventions formal-build-designation and interim-build-designation are defined as: formal-build-designation = release | ... interim-build-designation = interim | nightly | snapshot | ... In other words, tools may use release, interim etc, but may also extend them to define their own. Tool support Tools can unambigously locate
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] java artifact specifier v0.1
On Fri, 14 Nov 2003 08:16 pm, Michal Maczka wrote: The only purpose of type in maven is to indicate how it is processed by the runtime. (ie plugins get installed, jars get added to classpath etc). It does not even specify that extension as there is a M-to-M between type and extension. ie. I don't agree that this is the only purpose of type. I think it's reasonable to have type directory as this can separate artifact produced by various tools. ... I would like to have an exclusivity for adding artifacts to directories like (jars/sources/distribution). But I could accept if somebody (some tool) is keeping its files in sibling directories. Also some exotic artifacts are making the repository harder to navigate. Sounds reasonable. But maybe the term type is not the best term for this as it does not designate a type but a arbitary subdivision of space based on usage patterns. Not sure what a better term would be? -- Cheers, Peter Donald The true measure of a man is how he treats someone who can do him absolutely no good. - Samuel Johnson (1709-1784)
RE: [proposal] common build version specifier - v0.1
From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Saturday, 15 November 2003 2:54 PM To: [EMAIL PROTECTED] Subject: Re: [proposal] common build version specifier - v0.1 Tim, I *love* your specifications, I really appreciate the clear/concise/explicit nature of them. I only wish you'd use Wiki not EyeBrowse as your persistent documentation tool. Wiki has versioning (so we can see older copies should we need to refer back) and such, and allows other to make (respectful) changes, and allows a view not cluttered throughout mail threads. I'm game to be your cut-n-paste-wallah if you really need one, but please (at least) refer to your proposals in the Wiki. regards OK. I'm not particularly wiki literate (the formatting is a bit off), but I've added/updated the proposals at: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Proposals Regards, Tim
RE: [proposal] java artifact specifier v0.1
From: Peter Donald [mailto:[EMAIL PROTECTED] On Fri, 14 Nov 2003 08:16 pm, Michal Maczka wrote: The only purpose of type in maven is to indicate how it is processed by the runtime. (ie plugins get installed, jars get added to classpath etc). It does not even specify that extension as there is a M-to-M between type and extension. ie. I don't agree that this is the only purpose of type. I think it's reasonable to have type directory as this can separate artifact produced by various tools. ... I would like to have an exclusivity for adding artifacts to directories like (jars/sources/distribution). But I could accept if somebody (some tool) is keeping its files in sibling directories. Also some exotic artifacts are making the repository harder to navigate. Sounds reasonable. But maybe the term type is not the best term for this as it does not designate a type but a arbitary subdivision of space based on usage patterns. Not sure what a better term would be? I thought of using category but opted for type simply because it is shorter. -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
click through license support?
One of the current problems with repositories such as http://www.ibiblio.org/maven is their inability to host products which have restrictive licensing schemes. (See http://maven.apache.org/sun-licensing-journey.html for background) E.g, ibiblio cannot host jars from Sun, because of the requirement that users must manually accept Sun's license before downloading the jars. This reduces the usefulness of using the repository for dependency resolution. I see several possible workarounds for this: Virtual hosting --- With this approach, none of the artifacts are hosted within the public repository. http redirection is used to direct 'virtual' artifact accesses to the real artifact. The limitation of this approach is that automatic artifact resolution can only work if the redirect is to the real artifact. This rules out all of the Sun jars which require acceptance of Sun's license first. A tool can 'screen scrape' the redirected page, prompt the user to accept the license and only download if the license is accepted, but this doesn't work in the general case. Direct hosting -- With this approach, artifacts are hosted within the public repository, but download is only enabled if the user agrees to the license. This implies that http redirection must be used and that tools have to be intelligent enough to handle the redirection and prompt the user. The limitation of this approach is that direct hosting can only be supported if an agreement can be made with the license holder. Thoughts?
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
Use of '/' in ???-specifier's
Given this spec repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier What is the version of this URL http://repo.apache.org/org/apache/commons/nightly/alpha/1.0/foo.jar * Projet commons, version Nightly 1.0 alpha * Project commons-nightly, version 1.0 alpha * Project commons-nightly-alpah version 1.0 (release) I think we should tighten the spec enough so we can at least tell the access, product,version, and artifact specifiers appart. R, Nick
RE: Use of '/' in ???-specifier's
From: Nick Chalko [mailto:[EMAIL PROTECTED] Given this spec repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier What is the version of this URL http://repo.apache.org/org/apache/commons/nightly/alpha/1.0/foo.jar * Projet commons, version Nightly 1.0 alpha * Project commons-nightly, version 1.0 alpha * Project commons-nightly-alpah version 1.0 (release) I think we should tighten the spec enough so we can at least tell the access, product,version, and artifact specifiers appart. R, Nick The URI isn't valid, according to http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier as a nightly build is an interim build: interim-build = interim-build-designation / version [ / interim-version ] interim-version = latest | MMDD [- HHMM [SS]] interim-build-designation = interim | nightly | snapshot | ... version = latest | *pchar IOW, one of alpha or 1.0 is invalid. However, given the URI: http://repo.apache.org/org/apache/commons/nightly/1.0/20031113/jars/foo-1.0. jar it is possible to determine the version using the common build version specifier and java artifact specifier proposals, by parsing the URI from right to left. It isn't possible to separate the organisation from the directory component of access-specifier however. e.g. given: http://repo.apache.org/org/apache/ it could be interpreted as: . directory = org, organisation = apache . directory = , organisation = org/apache -Tim
Re: Use of '/' in ???-specifier's
Tim Anderson wrote: The URI isn't valid, according to http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier -Tim Try this one http://repo.apache.org/org/apache/commons/alpha/1.0/foo.jar * Projet commons, version 1.0 alpha * Project commons-alpha, version 1.0 * Project alpha version 1.0 I know this is contrived, but it does highlight the inablity to tell where one specifier ends, and onther begins. R, Nick
Re: click through license support?
Tim Anderson wrote: ... Virtual hosting --- With this approach, none of the artifacts are hosted within the public repository. http redirection is used to direct 'virtual' artifact accesses to the real artifact. The limitation of this approach is that automatic artifact resolution can only work if the redirect is to the real artifact. This rules out all of the Sun jars which require acceptance of Sun's license first. A tool can 'screen scrape' the redirected page, prompt the user to accept the license and only download if the license is accepted, If the tool is made to work like a web browser, ie show the pages and then download when the user clicks on the button, IMHO it would be perfectly acceptable. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
[proposal] java artifact specifier - v0.2
Overview This proposal extends the URI Syntax proposal: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax It is recommended, but not required, that it be used in conjunction with the Common Build Version Specifier proposal: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier The key aims of this proposal are to: . formalise artifact-specifier for java based projects . provide a set of best practices for such projects; and . enable tools to construct a URI to unambigously locate a particular java project artifact using a set of known criteria Java project artifacts include, but are not limited to: jars, wars, rars, tlds, source, binary and document distributions, and licenses. URI Components == An absolute repository URI is written as follows: repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier For java project artifacts, artifact-specifier is: artifact-specifier = java-project-artifact java-project-artifact = java-artifact | distribution-artifact | signature-artifact | signature-keys | license-artifact Java artifacts -- Java artifacts include, but are not limited to, jars, wars, rars, and tlds. java-artifact = jar-artifact | war-artifact| rar-artifact | tld-artifact | path_segments jar-artifact = jars / versioned-artifact-name .jar war-artifact = wars / versioned-artifact-name .war rar-artifact = rars / versioned-artifact-name .rar tld-specifier = tlds / versioned-artifact-name .tld (path_segments is per http://www.ietf.org/rfc/rfc2396.txt) Versioned artifact names Java and distribution artifacts include the project version: versioned-artifact-name = artifact-name - short-version [debug] artifact-name = pchar+ short-version = version-name [- timestamp] debug = -dbg (version-name and timestamp are per http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier) (pchar is per http://www.ietf.org/rfc/rfc2396.txt) Artifacts can indicate that they include debugging information via the -dbg suffix. E.g: ant-1.5.4.jar ant-1.5.4-20031113.1043.jar ant-1.5.4-dbg.jar Distribution artifacts -- Distribution artifacts include binary, source, and documentation distributions: distribution-artifact = binary-artifact | source-artifact | doc-artifact binary-artifact = binaries / versioned-artifact-name -bin . arc-ext source-artifact = source / versioned-artifact-name -src . arc-ext doc-artifact = document-artifact | javadoc-artifact document-artifact = docs / versioned-artifact-name -doc . arc-ext javadoc-artifact = docs / versioned-artifact-name -javadoc . arc-ext arc-ext = tar.gz | zip | bzip2 | ... E.g: binaries/ant-1.5.4-bin.zip binaries/ant-1.5.4-dbg-bin.tar.gz source/ant-1.5.4-src.zip source/ant-1.5.4-src.tar.gz docs/ant-1.5.4-doc.zip docs/ant-1.5.4-javadoc.zip Signatures -- An artifact may have an associated PGP, MD5, or SHA signature artifact, located alongside it: signature-artifact-specifier = java-project-artifact . sig-type sig-type = pgp | md5 | sha | ... E.g: 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-1.5.4.jar.pgp http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar.sha Where a signature has associated keys, these are specified by: signature-keys = sig-type / KEYS E.g: http://repo.apache.org/apache/ant/1.5.4/pgp/KEYS Licenses license-specifier = licenses / license-name license-name = LICENSE.txt | path_segment (path_segment is per http://www.ietf.org/rfc/rfc2396.txt) Rationale = Artifacts in subdirectories --- Each category of artifact in this proposal is required to be located in its own directory, e.g: jars/commons-cli-1.0.jar rather than in the root project version directory. The alternative approach of placing each artifact in the root makes repository navigation harder, particularly for projects: . which deploy with large numbers of artifacts . which deploy artifacts other than those defined by this proposal. Inclusion of version in artifact names -- Java and distribution artifacts require that the version be included in their names: versioned-artifact-name = artifact-name - short-version [debug] short-version = version-name [- timestamp] This ensures that it is immediately obvious to users what version of an artifact they are using, subsequent to its download. The optional timestamp indicates interim builds, as per:
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
