> Not a criticism, but I'd prefer to know the requirements, > before writing the tools.
I know, I've been a huge advocate of that, but I'm starting to worry we are in analysis paralysis. Logical URIs are so virtual it is easy to miss practical implications. As such, I'd like to test the theory against "the tool implementation in my head". That said, we need to revisit requirements, especially the tooling aspect of that. As Nick said "having a tool know/display/process what is in a remote repostiory" w/o metadata is my goal. > As far as I can tell, maven doesn't do URI parsing. > I don't know a lot about Gump, but if it wants to pull down the > newest versions of jars, it can via the "latest" version tag [1]. Gump (like Maven) has metadata also, so could ask for a certain version of something. That said, we are talking about "client side metadata" with all of these, not "in repository metadata". As such, this information is not in the repostory (per se) and so **not available to repository tools**. This is the key point. FWIIW: I *hate* maintaining version information in metadata (in CVS or not) 'cos I think it leads to stale links, and to too much duplication. I think I've said this (once or twice ;-) before though. BTW: I'd like the repository to work independent of client metadata, so we have a consistent repository however tools use it. Maybe we'll have a metadata.xml per directory that we can all agree upon, and extend, but that isn't what we have here and now. > Avalon adds meta-data, which is supported through > the statement in [2]: > "Projects should be able to deploy arbitrary artifacts to the repository, > whether they be for end-users, or meta-data (e.g, maven's project.xml). > Tools should ignore any artifact they don't understand." Yup, but I'd like to see some cross-project-type tools possible. I'd like tools to be able to work against all types of artefacts, built by Maven, by Gump, by whomever. regards Adam
