1. startup time. In order to load one library you need to process all of them. It can be resolved with caching the result and looking at .jar modifications. Most likely we'll have dozens of antlibs - and that'll only grow in time. The processing of (all) TLDs at startup ( for tomcat ) adds a very visible overhead on startup, and at least tomcat is a long-running process.


2. Placing multiple antlibs in a single jar may be trickier.


3. It may place too much emphasis on the .jars and filesystem layout.


4. A bit harder to control ( as we know from c-logging and JAXP ),


5. Explicit control over what antlibs are to be used - versus loading everything. Well - I like "magic" loading, but a lot of things in ant are done explicitely.

I have no problem accepting a getResources() solution ( just like I'm ok with using XML - but not any XML :-), but those issues should be considered.
A lot of the "mess" in ant is the result of doing some things without considering all implications or just as side effect of how code happened to work. That's why I'm so strongly for breaking things down to individual problems instead of a bundle solution.