On Dec 5, 2004, at 6:23 PM, Russell Gold wrote:
On Sun, 5 Dec 2004 06:57:09 -0500, Erik Hatcher
<[EMAIL PROTECTED]> wrote:
I can't think of any sound reasons for preserving hierarchy in
WEB-INF/lib.

Some vendors, especially of commercial software, choose to distribute their products as multiple jars. And some of them attempt to identify "primary" vs. "subordinate" jars through a hierarchy. Those jars then know about their relative locations and depend on them in their manifest classpaths. If you arbitrarily flatten your hierarchies you will get ClassNotFound exceptions in such cases.

From Servlet 2.4 specification, section 9.5:

"The /WEB-INF/lib/*.jar area for Java ARchive files. These files contain servlets,
beans, and other utility classes useful to the Web application. The Web application
class loader must be able to load classes from any of these archive
files.


The Web application class loader must load classes from the WEB-INF/ classes
directory first, and then from library JARs in the WEB-INF/lib directory. Also, any
requests from the client to access the resources in WEB-INF/ directory must be
returned with a SC_NOT_FOUND(404) response."


There is later verbiage that says:

"Web containers must also 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."


So it is ambiguous, at least to me (one part says "in" another says "under"), whether a hierarchy under WEB-INF/lib is kosher or not. I have never used anything but a flat structure there, and likely never will.

I would very much like to see the <lib> element flatten, or some way to
flatten any arbitrary fileset. I end up doing a <copy> to flatten a
hierarchical directory before using <lib>, which is sub-optimal.

Ant already has a concept of a mapper type, typically used for copy operations.

Yes, I know :)

 It would be entirely consistent to extend its use to the
<lib> subtask (which essentially does a copy in any case). Cake and
eat it, too.


<lib> is not a subtask, per se. It is a fileset datatype. The difference currently is that datatypes don't "do" anything, but contain data that tasks use. So while I'd love a flatten mapper on <lib>, I'm not sure it is consistent and makes sense in all places that a fileset can be used. I realize that the difference between a task and datatype has gotten smaller in 1.6, though.


        Erik


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to