> 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
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 .
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 :
> "Projects should be able to deploy arbitrary artifacts to the
> 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.