[proposal] common distribution artifact specifier v0.1
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 source and binary distributions; . support platform-independent and platform-specific distributions; . provide a set of best practices for such artifacts; and . enable tools to construct a URI to unambigously locate a particular distribution artifact 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 For distribution artifacts, artifact-specifier is: artifact-specifier = distribution-artifact distribution-artifact = binary-artifact | source-artifact Binary artifacts binary-artifact = platform-independent-binary | platform-specific-binary platform-independent-binary = bin-prefix / versioned-artifact-name bin-suffix platform-specific-binary = bin-prefix / os-name / versioned-platform-artifact-name bin-suffix bin-prefix = binaries os-name = pchar+ bin-suffix = -bin . arc-ext arc-ext = tar.gz | zip | exe | pchar+ (pchar is per http://www.ietf.org/rfc/rfc2396.txt) E.g: binaries/linux/httpd-2.0.40-i686-pc-linux-gnu-rh73-bin.tar.gz binaries/win32/apache-2.0.48-win32-x86-bin.exe binaries/commons-cli-1.1-bin.tar.gz Source artifacts source-artifact = platform-independent-source | platform-specific-source platform-independent-source = src-prefix / versioned-artifact-name src-suffix platform-specific-source = src-prefix / os-name / versioned-platform-artifact-name src-suffix src-prefix = source src-suffix = -src . arc-ext E.g: source/commons-cli-1.1-src.zip source/solaris/httpd-2.0.43-sparc-sun-solaris-2.8-src.tar.gz Platform independent artifacts -- Platform independent artifacts include the project version: versioned-artifact-name = artifact-name - short-version [debug] artifact-name = pchar+ short-version = version-name [- timestamp] (version-name and timestamp are per http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier) E.g: ant-1.5.4-src.tar.gz ant-1.5.4-20031113.1043-bin.zip ant-1.5.4-dbg-bin.tar.gz Platform specific artifacts --- Platform-specific distribution artifacts include the project version and platform: versioned-platform-artifact-name = artifact-name - short-version platform [debug] artifact-name = pchar+ short-version = version-name [- timestamp] plaform = pchar+ os-name = pchar+ Debug information - Artifacts can indicate that they include debugging information via the -dbg suffix: debug = -dbg E.g: commons-cli-1.1-dbg-bin.zip httpd-2.0.43-sparc-sun-solaris2.8-dbg-bin.tar.gz Rationale = Artifacts in subdirectories --- Each category of artifact in this proposal is required to be located in its own directory, e.g: binaries/commons-cli-1.0.tar.gz 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 that: . deploy large numbers of artifacts . deploy artifacts for multiple platforms . deploy artifacts other than those defined by this proposal. Inclusion of version and platform in artifact names Distribution artifacts require that the version be included in their names. Platform specific artifacts are required to also specify the platform: versioned-artifact-name = artifact-name - short-version [debug] versioned-platform-artifact-name = artifact-name - short-version platform [debug] short-version = version-name [- timestamp] This ensures that it is immediately obvious to users what version and platform of an artifact they are using, subsequent to its download. The optional timestamp indicates interim builds, as per: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier Tool support Tools can unambigously locate an artifact within a project version given the following criteria: . artifact type Mandatory. . artifact name Mandatory. . OS name. Mandatory for
Summary of repository URI proposals
There are now four proposals available at: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Proposals . Repository URI Syntax http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax This specifies the core URI layout, which the other proposals extend. . Common Build Version Specifier http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier This specifies versioning for projects which perform formal and interim builds. . Common Distribution Artifact Specifier http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonDistributio nArtifactSpecifier This specifies the URI format for source and binary distribution artifacts. . Java Artifact Specifier http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/JavaArtifacts This specifies the URI formats for java artifacts. To do - . change Java Artifact Specifier to refer to Common Distribution Artifact Specifier, for source and binary distributions . factor out signature-artifact-specifier and signature-keys from Java Artifact Specifier, into a new proposal, (Signature Artifact Specifier?), as it is relevant to Common Distribution Artifact Specifier as well. . factor out license-specifier from Java Artifact Specifier, into a new proposal, (License Artifact Specifier?), as it is relevant to Common Distribution Artifact Specifier as well. . determine what additional support is required for C/C++ projects. Common Distribution Artifact Specifier aims to handle binary and source distributions for these projects - what else is required? . move common BNF somewhere else. E.g: versioned-artifact-name artifact-name short-version debug arc-ext are contained in both Java Artifact and Common Distribution Artifact Specifiers. -Tim
Re: Use of '/' in ???-specifier's
Nick Chalko wrote: 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. +1 Steve. R, Nick -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | ||
RE: Use of '/' in ???-specifier's
From: Stephen McConnell [mailto:[EMAIL PROTECTED] Nick Chalko wrote: 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. +1 Steve. A repository URI cannot be parsed simply based on repository-uri. It needs to be used in conjunction with the other proposals before any information can be derived. As stated previously, the URI doesn't match the criteria supported by the other proposals. This doesn't mean that the URI is invalid, it simply means that it isn't supported by them. Tools that are based on the proposals should therefore ignore it. Alternative approaches would be to: . limit each *-specifier to a single path segment (i.e, disallow /) Hopefully, the proposals show that this is too restrictive . include delimeters in the URI E.g, http://repo.apache.org/organisation/apache/project/foo/version/... Duplicate information, and just plain *ugly*. -Tim
Re: Use of '/' in ???-specifier's
Tim Anderson wrote: From: Stephen McConnell [mailto:[EMAIL PROTECTED] Nick Chalko wrote: 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. +1 Steve. A repository URI cannot be parsed simply based on repository-uri. It needs to be used in conjunction with the other proposals before any information can be derived. As stated previously, the URI doesn't match the criteria supported by the other proposals. This doesn't mean that the URI is invalid, it simply means that it isn't supported by them. Tools that are based on the proposals should therefore ignore it. Alternative approaches would be to: . limit each *-specifier to a single path segment (i.e, disallow /) Hopefully, the proposals show that this is too restrictive . include delimeters in the URI E.g, http://repo.apache.org/organisation/apache/project/foo/version/... Duplicate information, and just plain *ugly*. Tim: I'm really not agree or disagreeing at this time - I just have a feeling in my bones that something is wrong. As such - consider this as simple rambling by someone who has not captured the big picture. After heading down to the cafe for a quick break - when walking back my thinking is that maybe the [organization]/[product] notion is artificial. What [organization]/[product] and [organization]/[product]/[version] do is to establish a path to an logical artifact. I can't get away from that conclusion that we should not be focussing on the url as a spec - but instead we should be focussing on the url as a [artifact-identifier] and from that point on we should be using metadata to provide us with the information about organization, product name, available versions, etc. But this presuposes that atrifact is something more abstract than a file - and I'm guessing that your idea of artifact is equivalent to file. Appologies here because I'm not keen on being the odd-guy out - and I don;t want to disrupt the flow. But at the same time I want to see a good result from this. And from that point of view - my own feeling is that we should *not* be focussing on the url as the base layer - but instead focus on what is the meta descriptor and its MIME relationship *then*focusus on how to access this via a url. But I could easily be totally wrong because I'm still in digesting/thinking mode. Cheers, Steve. -Tim -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | ||
RE: Use of '/' in ???-specifier's
maybe the [organization]/[product] notion is artificial. What [organization]/[product] and [organization]/[product]/[version] do is to establish a path to an logical artifact. At any of it does is establish a path to a logical artifact. Seems to me that there is limited utility to being able to parse the URI, and that the real key is having meta-data with which to assemble it. But others don't seem to agree with that view. They want to parse semantic information from the URI. we should not be focussing on the url as a spec - but instead we should be focussing on the url as a [artifact-identifier] and from that point on we should be using metadata to provide us with the information about organization, product name, available versions, etc. So your feeling is that once you have a URI for the root component for a tool, you want meta-data suitable for your tool to indicate the location(s) of other content, such as license, dependents, etc. Those location(s) can be specified either by a full URI, or after all of Tim's good work, by URI parts, which the specification tells us how to assemble. The latter is how I have been viewing things so far. The meta-data could be in the form of a POM, a JNLP file, or some other format, and the tool would indicate what it is looking for as previously discussed. I think that's where you're going, right? I'm not keen on being the odd-guy out I don't think that you are. There may be some undocumented assumptions going on, and this helps to clarify them. For example, the above may help explain to Adam why I have been unconcerned about the ability to unambiguously parse a URL, whereas I do care about being able to assemble one. --- Noel
Re: Use of '/' in ???-specifier's
Noel J. Bergman wrote: maybe the [organization]/[product] notion is artificial. What [organization]/[product] and [organization]/[product]/[version] do is to establish a path to an logical artifact. At any of it does is establish a path to a logical artifact. Seems to me that there is limited utility to being able to parse the URI, and that the real key is having meta-data with which to assemble it. But others don't seem to agree with that view. They want to parse semantic information from the URI. we should not be focussing on the url as a spec - but instead we should be focussing on the url as a [artifact-identifier] and from that point on we should be using metadata to provide us with the information about organization, product name, available versions, etc. So your feeling is that once you have a URI for the root component for a tool, you want meta-data suitable for your tool to indicate the location(s) of other content, such as license, dependents, etc. Those location(s) can be specified either by a full URI, or after all of Tim's good work, by URI parts, which the specification tells us how to assemble. The latter is how I have been viewing things so far. The meta-data could be in the form of a POM, a JNLP file, or some other format, and the tool would indicate what it is looking for as previously discussed. I think that's where you're going, right? In principal ... yes. But I am making an assumption that a very simple named value pair metadata syntax could be assumed along with a meta mime type. References in that structure could be absolute or relative to the location of the metadata file. Releative to the java world - that schema could be equivalent to the Properties format (i.e. some-name = some-value). Given something like this - it becomes a lot simpler to seperate mechanics of access from logic of usage, while maintaining potential for cross-application interoperability (although that would require at least a very very small set of standard properties - e.g. language and application domain). Cheers, Steve. I'm not keen on being the odd-guy out I don't think that you are. There may be some undocumented assumptions going on, and this helps to clarify them. For example, the above may help explain to Adam why I have been unconcerned about the ability to unambiguously parse a URL, whereas I do care about being able to assemble one. --- Noel -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | ||
meta-data formats
Stephen, The meta-data could be in the form of a POM, a JNLP file, or some other format, and the tool would indicate what it is looking for as previously discussed. I think that's where you're going, right? In principal ... yes. But I am making an assumption that a very simple named value pair metadata syntax could be assumed along with a meta mime type. References in that structure could be absolute or relative to the location of the metadata file. That would be a possible meta-data format, but there are already others, such as Maven's POM or Sun's JNLP. The goal, IMO, would be to provide suitable content appropriate to the requesting client. I think we need to facilitate the mechanism, not dictate the possible meta-data formats. --- Noel
