----- Original Message -----
From: "Earl Hood" <[EMAIL PROTECTED]>
> In the work I have done, the solution to this problem is to merge
> the necessary jar files together to avoid the dependency on CLASSPATH.
> The merging is not ideal for some applications, like applets, but
> works well for server-side, or stand-alone, applications. It makes
> distribution and installation easier.
>
> To do the merging, I wrote some classes that do the merging processing
> (using jar to do the work is inefficent and awkward). It attempts to
> preserve manifest information and supports selective inclusion and
> exclusion of classes; this allows one to merge only what is needed.
> If there is interest, I can make the source available.
Sounds like a possible inclusion in the ant tasks sandbox area?
> Wrt log4j, you could include the log4j jar file with Cactus and then
> merge it into the jar file (or files(?), I am not familiar with Cactus)
> during the build so all necessary log4j classes are available. For a
> project I am working on where I work, this is what I do. I also
> include a default log4j.properties in our base library so log4j does
> not complain if the application does not provide one.
Agreed. Maybe we all need is just a micro log4j distribution that contains
the bare minimum (handful?) of classes (the facade & a couple of
implementation classes) to get some real basic logging by default for
projects that feel they need it. Then users could always swap in the full
log4j if they want more control & flexibility.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
