Tim Anderson wrote:
*repository-uri = access-specifier "/" product-specifier "/" version-specifier "/" artifact-specifier*Can you provide an example of a URI which can't be parsed?
-Tim
[1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax
It defines *access-specifier* and *product-specifier*, but leaves *version-specifier* and *artifact-specifier* opaque, to be defined by language, platform, or artifact-specific best practices.
Since version-specifier and artifact-specifier are opaque, there is no way to tell where product specifier ends. I know we have suggested version, and a Java artifact specifier. But what about other languages, Like the "new cool O/S" language foo.
It's artifact's are called bars
http://repo.com/org/foo/cat/dog/bars/bar.zip
What is the product org.foo.cat or org .foo?
Is cat the version name or is dog.?
Perhaps there are two kings of bars, one for dogs and one for eggs. or what ever.
If we want to leave version specifier and artifact specifier opaque then I think it is important to harden the product specifier. Some limits to version might be acceptable, but artifact should definitely be opaque.
organization/project is a workable solution that lets a tool make intelligent guesses based on URI only,.
I like the simplicity of Top level = Organization that distribute things
2nd level = A project. (a sub organizational unit that
distributes artifacts)
3/4 level = Version, (interim builds take an extra level
4/5 = Artifacts stored any what a project likes. (with best
practices for Java and other languages.)
The ONLY limits we have on organization and project and version is
it must be valid URI character and it can not be a "/" (ie pchar)
R, Nick
