> 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 http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar 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 repository however. > > > [...] 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 > >
