> >Why not just "<protocol>://<repository-path>/artifact-name", where artifact > >name is as qualified as necessary, and is permanent? The project name, > >sub-project relationships, versioning, etc., could all be handled by the > > descriptor contents.
> So http:repo.apache.org/ant would return a discriptor such as > <project name="ant" > > <jar ...> > <depends ...> > </project> Yes and I don't know. Yes to the concept, and I don't know to the specifics. I would expect the <jar> and <depends> elements, for example, to be wrapped inside of version elements. Maybe something conceptually similar to: <project name="proj"> <title>...</title> <description> ... </description> <license> ... </license> <versions stable="stable-label" beta="beta-label"> <version label="label-1"> <version label="label-2"> ... </versions> <version label="label-1"> <description> ... </description> <license> ... </license> <requirements> ... </requirements> <platforms> ... </platforms> <processors> ... </processors> <packages> ... </packages> </version> </project> Incomplete, even within the context of this example. These are just seeds of an idea to elicit a community response and further evolution. There is prior art in this area that ought to be incorporated (Maven, GUMP, JNLP, ports, debian, etc.). With respect to the above, there are two semantics to clarify: 1. Elements inside of <project> are project defaults. Elements inside of <version> override the defaults. This allows for brevity and flexibility. 2. The <version> elements inside of <versions> were my idea of an easily usable TOC, rather than expand all of the "real" <version> elements in-line. There are clearly things even in that example that need to be shuffled. For example, consider platform-specific binary releases. Same version, but different processor or operating system type would need to yield a different set of packages. I put them into the example purely in the cateogry of "food for thought." So, as I said, yes and I don't know. The idea you expressed it what I have in mind as a concept, but I don't claim a firm grasp on what should be the formal schema. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]