Brill, I've been reading along, and I agree that you have a valid use case. However, this is all academic until you send in some sort of patch. I might even use this patch if it were sent in - but I don't have time to develop it myself. Sorry, but you're starting to put the cart before the horse here...submit a patch, _then_ nag (pardon the expression) the committers [on the -dev list, BTW] for attention. If you send in a patch, I'll look at it and discuss it with you...then, maybe I'll help you lobby for it (I'm not certain of my status wrt committing plugins; this is something that's been generally up for debate recently). But understand, the only help I'll offer in any capacity will be subject to my own availability. Just as I'm sure you have, I have a day job that doesn't center on maven. :)
HTH, john On Wed, 2004-06-30 at 10:44, Brill Pappin wrote: > Ok, let me explain this one more time. > > What you are saying is indeed part of the servlet spec, and the > container may actually read and care about what's in the WAR manifest, > however code running in the application context doesn't know, and > doesn't care. > It doesn't care because for things to be working, the webapp must be > working properly already and if it wasn't the code running in the > context would have other problems anyway. > > By allowing a user to jar up and add a manifest for the *application > code* you allow the user to specify all sorts of meta information about > the code at runtime (as mentioned in the versioning spec). The > application code runs in the containers context but the versioning > information *for the war* means nothing to the application itself, in > fact the versioning API can't even get the WARs versioning information > (at least not in any container I use), but it *can* get versioning > information for the libraries it depends on which means the user code > that was JAR'ed up. > > An example of where I specifically use this information: > I'm sure you've seen how you have have log4j output the file and line > number of a log message. Now using the versioning API you can also > output other information as well as the file and line number, such as > what version it is, the module or company it came from... you can even > tell things like what dependencies it has etc. > > As you can see it would be pretty useless to anything but the webapp > container to have all this in the WAR file. Not only would it no longer > be relevant to the runtime code, but all libraries in the context would > have the same information. > > I hope I am being clear here because I can't think of a simpler was to > describe this. > > For those interested in more detail, the versioning spec is at: > http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html > > As an aside, Maven might be able to use this to determine the dependency > structure of a library which I know if a holy-grail for the first > release, but I leave that to the folks working on the artifact stuff. > > - Brill Pappin > > Maczka Michal wrote: > > > Here is what spec says: > > > >"Web containers are recommended to have a mechanism by which web > >applications can learn what JAR files containing resources and code are > >available, > >and for making them available to the application. Containers should provide > >a > >convenient procedure for editing and configuring library files or > >extensions. > >It is recommended that Application developers provide a META-INF/ > >MANIFEST.MF entry in the WAR file listing extensions, if any, needed by the > >WAR. > >The format of the manifest entry should follow standard JAR manifest format. > >In > >expressing dependencies on extensions installed on the web container, the > >manifest entry should follow the specification for standard extensions > >defined at > >http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html. > >Web Containers should be able to recognize declared dependencies expressed > >in the manifest entry of any of the library JARs under the WEB-INF/lib entry > >in a > >WAR. If a web container is not able to satisfy the dependencies declared in > >this > >manner, it should reject the application with an informative error message." > > > >So realy the spec makes no difference between any of the manifest files > >which are provided inside wars > >and clearly defines where they can be placed. > >But for strange reason it says: "It is recommended that Application > >developers provide a META-INF/MANIFEST.MF entry in the WAR file listing > >extensions". > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
