ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: <libraries>& cache
Date Mon, 06 Dec 2004 10:27:12 GMT
On Dec 5, 2004, at 6:23 PM, Russell Gold wrote:
> On Sun, 5 Dec 2004 06:57:09 -0500, Erik Hatcher
> <> 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 
class loader must be able to load classes from any of these archive

The Web application class loader must load classes from the WEB-INF/ 
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 
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 

>> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message