I'm not too good with the Jelly script but I'll see what I can come up with and send it though the "normal" channels.
Yes, I do have a day job :) which means that I don't have fixed amount of time to work this problem, particularly not being familiar with Jelly.
- Brill Pappin
John Casey wrote:
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
