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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTE] Where is version in UIR Syntax
Just based on opinions registered so far - it seems that the notion of version in the path has concensus and that the real question and difference between the two position holding attention is if a version in the filename should be manadatory or not. Is that a reasonable conclusions? Stephen. Nick Chalko wrote: 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 -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | ||
Re: [VOTE] Where is version in UIR Syntax
Stephen McConnell wrote: Just based on opinions registered so far - it seems that the notion of version in the path has concensus and that the real question and difference between the two position holding attention is if a version in the filename should be manadatory or not. Is that a reasonable conclusions? Seems that is where we are at. To me I can live with either. R, Nick Stephen. smime.p7s Description: S/MIME Cryptographic Signature
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
Re: [VOTE] Where is version in UIR Syntax
Nick Chalko wrote: Stephen McConnell wrote: Just based on opinions registered so far - it seems that the notion of version in the path has concensus and that the real question and difference between the two position holding attention is if a version in the filename should be manadatory or not. Is that a reasonable conclusions? Seems that is where we are at. To me I can live with either. Hi Nick: Just for reference - I use non-versioned artifact referenced rather frequently. Typically I'll create a symlink to a versioned artifact. The main benefit is when end-users are deploying artifacts and your giving them a URL. From my point of view is simply more friendly to make this optional - and I think more practical in the long term. Stephen. p.s. BTW - I've sorted out how he can deal with meta resolution without impacting the spec - thanks to Noel's links re. http which lead to some learning about content negotiation and with some assisstance from Erik Abele from infrastructure, I managed to get in place a test case that allows me to pull down artifact metadata by requesting a text/x-meta mime type. SJM R, Nick Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | ||
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] java artifact specifier v0.1
On Thu, 13 Nov 2003 09:04 pm, Michal Maczka wrote: Yes - you are right they don't differ in this purpose. But it doesn't mean that one of them is not need. I think that repository is easily navigated when both groupId and type directories co-exits. I guess what I saying is why not collapse both of them into one given that there is no distinction in purpose or in implementation. 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. X.jar -- jar, ejb distribution -- .tar.gz, .tar.bz2 -- Cheers, Peter Donald Copy from one, it's plagiarism; copy from two, it's research. - Wilson Mizner (1876-1933)
Re: [proposal] java artifact specifier v0.1
Peter Donald wrote: On Thu, 13 Nov 2003 09:04 pm, Michal Maczka wrote: Yes - you are right they don't differ in this purpose. But it doesn't mean that one of them is not need. I think that repository is easily navigated when both groupId and type directories co-exits. I guess what I saying is why not collapse both of them into one given that there is no distinction in purpose or in implementation. 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. For example Ant is not build with Maven (and never will be) but we can still add Maven's POM for Ant to the repository. The POM can be also added for Struts, Xerces etc. If some other tools like Gump need their own meta data they should be free to add it to the repository. But I question the fact if such files should be mixed with distributions. I don't like an idea of putting everything into one huge bag. If I were a Struts developer I would hate if somebody puts some strange artifacts into the directory which I maintain. 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. Why to mix them with importand artifacts? Michal
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 that there
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
