Eric Pugh wrote:
I guess one reason though to explicitly load up example.jar and example.jar.meta is that when I want to setup my own local repository it's easy, all I need to do is have a working webserver. additionally, if I want my repository to be just a file system, then it is the same...
One of the nice things about the maven repository was that setting up our own corporate one was dirt simple, and runs nicely on IIS. As soon as you need to configure meta mimetype you are going to have sysadmins telling you "No!"...
But that's ok. The client make make assumptions about a document named xxxx.jar.meta - but if the client ties to get this using a mime type first - then the server can resolve this using a dozen different mecanisms. That's the important point - we can transfer the implementation decision to the server and still maintain a fallback strategy on the client that is consitent with your local filesystem model.
Cheers, Steve.
Just something to keep in mind, and I'm looking forward to playing with your example..
Eric
http://www.apache.org/~mcconnell/test/example work. You-----Original Message----- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 3:59 PM To: Avalon Developers List Subject: Re: [repository] mime type addition?
Alex Karasulu wrote:
Ok I'm a little dense so bear with me. I see the webservernow recognizes
and sets the mime type based on the .meta file extension.Why is this so
significant to us?
It means that the client application (i.e. the repository implementation classes) can take advantate of the x-meta mime type. Based on the user supply of a group and artifact we can make a request for the meta data without resorting to a url that exposes anything more than the fgroup and artifact.
Specifically:
http://www.apache.org/~mcconnell/test/example
This url is sufficient for the retrival of the jar (a mime type) and the meta about the jar (another mime type). Instead of building an explict url to a <something>.meta - we can use HTTP content rules to get what we want (jar versus meta data about the jar). This means that the question of how meta data is associated with an artifact is no longer a client concern - its a server implementation concern.
Your example is also very confusing to me as well. Can youexplain it? Why
would trying to get
only have the following in this directory:
example.jar example.jar.meta
Yep.
The artifact url is http://www.apache.org/~mcconnell/test/example
Relative to that artifact there are a number of resources that are potentially resolvable - example.jar and example.jar.meta. According o the HTTP protocol spec we can set an "Accept" request property to guide the server in terms of content negotiation. I.e. the group/artifact is sufficent with respect to url - the rest can be resolved using content negotiation support.
http://httpd.apache.org/docs-2.0/content-negotiation.html
Steve.
(who is figuring this stuff out as he goes along).
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
