Let's try to work this one through to completion:
http://<host>/<group>/<type>/<id>[-<version>].ext
I think this is close to what some (most?) here are accustomed to, and are
comfortable with.
We need to enumerate <type> [in 'English', I have to assume,
jar/src/etc...], and later agree on <group> and <id>, but I believe this is
a fair stake in the ground. I think we need to assume that we'll have
repository versions (perhaps stored readable in metadata in the root) and
hope we can migrate folks, but we'd be daft to think we could get it right
first time. As such, I'd like to agree on this and move on (to metadata).
Two *minor* points:
1) From my parsing experience... We have issues if there is a -{n} inside
the <id> or if version does not start with a numeric. (That is, it is an
issue if we are using the repository as something to read standalone, and
not in conjunction with some client-side metadata.)
2) Also, I know the eclipse folk like an underscore as opposed to a hyphen.
Sure, they aren't ASF, but it'd be nice to be able to get full stacks easily
& folks build on top of Eclipse. Not sure how we deal with "non-conformist"
file formats. More metadata?
Dion, do you wish to manage some soft of draft/vote(or general
consensus)/agreement scheme on the Wiki? I feel that we need a clean/simple
way to present what we agree upon (maybe in Wiki), and can build upon, and
separate that from random thoughts.
regards,
Adam
--
Experience Sybase Technology...
http://www.try.sybase.com
