RE: Test/Prototypical Repository
> From: Ben Walding [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 25 November 2003 9:03 AM > > I'm still not convinced that "binaries" is better than "binary" as a > type directory. > > See my original comments that must have lost in the ether (section 2) - > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] > che.org&msgId=1124258 > [snip] "binaries" matches existing ASF practices, for both java and C distributions. Also, the directory name need not be reflected in the artifact extension - the directory is there simply to group similar artifacts. The proposals no longer refer to a 'type' directory. E.g, for java artifacts [1], artifact-specifier is: artifact-specifier = java-artifact-specifier java-artifact-specifier = jar-artifact | war-artifact| rar-artifact | ear-artifact | tld-artifact | javadoc-artifact jar-artifact = "jars" "/" versioned-artifact-name ".jar" war-artifact = "wars" "/" versioned-artifact-name ".war" rar-artifact = "rars" "/" versioned-artifact-name ".rar" ear-artifact = "ears" "/" versioned-artifact-name ".ear" tld-specifier = "tlds" "/" versioned-artifact-name ".tld" javadoc-artifact = "docs" "/" versioned-artifact-name "-javadoc" "." arc-ext arc-ext = "tar.gz" | "zip" | "bzip2" | ... -Tim [1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/JavaArtifacts
URI proposals updated
I've updated the proposals to incorporate some of the feedback received. Each proposal can be accessed from: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Proposals (this also contains an overview) Summary of changes: 1. constrained organisation in Repository URI Syntax http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax The organisation part may no longer contain nested "/" This restriction has been done to support URI parsing. 2. constrained version-name in Common Build Distribution Specifier. http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier The version-name may no longer contain reserved words. 3. Factored signature artifacts out of Java Artifact Specifier http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/SignatureArtifact Specifier 4. Factored license artifacts out of Java Artifact Specifier. http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/LicenseArtifactSp ecifier Preliminary only. 5. Restructured Java Artifact Specifier http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/JavaArtifacts . changed to refer to Common Distribution Artifact Specifier, Signature Artifact Specifier, and License Artifact Specifier . added ear-artifact . removed doc-artifact, as its not specific to java projects -Tim
RE: Use of '/' in ???-specifier's
> From: Stephen McConnell [mailto:[EMAIL PROTECTED] > > Nick Chalko wrote: > > > Tim Anderson wrote: > > > >> For advocates of URI parsing, what problems are you trying > >> to solve? > >> > >> > >> > >* Discovery of "what is available" > >* Repository exploring. > >* Auto cleanup of repositories. > > > > > > > > The URI spec is too loose. > > > I completely agree. > > But I just want to add that all I want is either (a) a simple structural > spec that does not imply more the 20 mins of concentration, or (b) > something auto-explanitory ... a.k.a. server side meta (which acording > to me is in scope relative to the objective of qualifying and > differentiating organization, artifact, version and all of the other > semantics that are currently being generalized. > > Today - we are not in the 20 min spectrum. > > Stephen. > I would dispute (a), but I'll admit I'm biased. The proposals are public and can be edited and improved by anyone. If you feel there are changes that can be made to improve readability, go ahead - I claim no ownership - much of the content has been distilled from earlier discussions and current ASF practices. As for (b), put forward a proposal. -Tim
RE: licensing issues for virtual artifacts (was RE: click through license support?)
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 26 November 2003 1:34 PM > > Nicola Ken Barozzi wrote > > [EMAIL PROTECTED] wrote: > > > I'm failing to see the requirement for us to do [virtual artifacts] > *now*. > > Because Apache projects using the repository would need also non-asf > > jars that we don't want to distribute -> virtual artifacts. > > I still maintain that non-ASF jars are specified in meta-data > made available > to client tools, and thus "virtual artifacts" are unnecessary. > > The meta-data files will need to be present repository in order for the > tools to work. > > --- Noel > The idea behind virtual artifacts is that they allow users and tools to determine if an artifact is available or not. Given the artifact: http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar A user browsing the repository on seeing "jndi-1.2.1.jar" can assume that a tool will be able to download it, regardless of whether the repository hosts it or not. Without the virtual artifact: . users might not be aware that corresponding meta-data indicates to tools that the real artifact is hosted elsewhere . tools would need to do a 2 stage lookup to find an artifact, even if its not present: 1. determine if the artifact is hosted directly 2. on failing [1], determine if there is any meta-data indicating that the tool should look elsewhere -Tim
