Dion,
Is there a reason why a project's repository URI cannot be orthogonal to
whatever file system naming convention is adopted for downloadable parts? I
think that it has to be orthogonal if we are to federate with other
repositories without having to incorporate them by value. And it supports
> >Why not just ":///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
>
>
Noel J. Bergman wrote:
Why not just ":///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 a
Why not just ":///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.
For the smart repository approach, if you want to add additional contraints
use a R
Noel J. Bergman wrote:
The point of
agreement is the format of the URI and the schema for the descriptor files,
and everything is mapped from there.
Then I propose the URI be
/projectname/[subproject]/[version]/artifactname
Which would allow a simple filesytem backend or an advanced smart s
Noel J. Bergman wrote:
The point of
agreement is the format of the URI and the schema for the descriptor files,
and everything is mapped from there.
Then I propose the URI be
/projectname/[subproject]/[version]/artifactname
Which would allow a simple filesytem backend or an advanced smart s
