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: URI Syntax: nightly and release builds
OK - so it should be at part of the java artifact specifier proposal [1], or do you envision another layer? The URI Syntax proposal [2] that the above extends is becoming a little thin. i.e: repository-uri = access-specifier "/" product-specifier "/" artifact-specifier ... product-specifier = organisation "/" project "/" version organisation = *pchar project = *pchar version = *pchar (pchar is per http://www.ietf.org/rfc/rfc2396.txt) becomes: ... product-specifier = organisation "/" project "/" version organisation = path_segments [3] project = *pchar version = path_segments (path_segments is per http://www.ietf.org/rfc/rfc2396.txt) organisation, version and artifact-specifier are therefore all opaque, determined by best-practices. -Tim [1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/JavaArtifacts [2] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax [3] to allow for FQDN and reverse FQDN, separated by "/". > -Original Message- > From: Stephen McConnell [mailto:[EMAIL PROTECTED] > Sent: Friday, 14 November 2003 12:55 PM > To: [EMAIL PROTECTED] > Subject: Re: URI Syntax: nightly and release builds > > > > Tim: > > My initial impression is that all the following could be expressed as > part of a spec. one-level-up from the artifact spec. Everything below > is dealing with the notion of the usage of the repository for a > particular purpose - namely the registration of artifacts arising from > development processes. It would be nice if we could draw a line between > the repository in its role as "artifact retrieval" as distinct from the > *usage* of the repository for a particular domain objective. > > Personally I figure this can be archived by layering on a usage specific > set of rules/best-practices on top of the [version] element. > > > Cheers, Steve. > > > > Tim Anderson wrote: > > >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/l
Re: URI Syntax: nightly and release builds
Stephen McConnell wrote: Tim: My initial impression is that all the following could be expressed as part of a spec. one-level-up from the artifact spec. Everything below is dealing with the notion of the usage of the repository for a particular purpose - namely the registration of artifacts arising from development processes. It would be nice if we could draw a line between the repository in its role as "artifact retrieval" as distinct from the *usage* of the repository for a particular domain objective. Personally I figure this can be archived by layering on a usage specific set of rules/best-practices on top of the [version] element. Yes I agree, A repo usage of version best practice document. Cheers, Steve. smime.p7s Description: S/MIME Cryptographic Signature
Re: URI Syntax: nightly and release builds
Tim Anderson wrote: The URISyntax proposal is silent on how to handle nightly, release, snapshot, and latest builds. This should be formalised. Very nicley thought out proposal. However first we should decide if we need to do anything with version. Why can't projects just all there versions whatever they want Nightly, daily, latest, current, alpha, beta, final, rc, gold, foo, bar, ... I don't think we need to specify anything about a version. We can also consider using redirects instead of symlinks for latest etc. R, Nick smime.p7s Description: S/MIME Cryptographic Signature
Re: URI Syntax: nightly and release builds
Tim: My initial impression is that all the following could be expressed as part of a spec. one-level-up from the artifact spec. Everything below is dealing with the notion of the usage of the repository for a particular purpose - namely the registration of artifacts arising from development processes. It would be nice if we could draw a line between the repository in its role as "artifact retrieval" as distinct from the *usage* of the repository for a particular domain objective. Personally I figure this can be archived by layering on a usage specific set of rules/best-practices on top of the [version] element. Cheers, Steve. Tim Anderson wrote: 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://rep
