> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: Sunday, 23 November 2003 5:25 PM
> > > How do you propose to implement such artifacts? What impact will
> > > that have on web site deployment and mirroring requirements?
> > Given the URI:
> > http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar
> > This could redirect to:
> > http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar.descriptor
> > The .descriptor file could have a specific mime type to let tools
> > know that they need to do additional processing, or they could rely
> > on the extension as an indicator.
> Whoa, so there is no reality for the artifact? We just redirect to a
> descriptor containing meta-data? I think we can clean that up, and we'll
> both be happy.
A zero-length file would be better, so it appears in automatically
generated indexes for users browsing the repository.
MD5 checksums etc can still be hosted within the repository alongside
the dummy jar, so tools can verify that what they get after
download is that which is expected.
Alternatively, require that the repository supports WebDAV,
don't use redirects, instead including the descriptor in
and assign it a content type of "application/artifact-descriptor",
to enable WebDAV aware tools that it is a descriptor rather
than a real jar. Could be misleading for users browsing the
> > [...] obtaining permission from the 3rd party first.
> And if they say no, we'll need to do it without such an artifact
> anyway, so
> we might as well drop the fiction.
> --- Noel