> >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]
