commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Resisting the temptation
Date Fri, 10 May 2002 13:17:11 GMT
Hi Ceki

Anyone who uses the digester needs digester, beanutils, collections and
logging. Its a shame there's not just a single jar for all these 4 (very
common) things. How about we bundle these 4 things into a single 'uber-jar'?
Say, commons-core.jar. We could maybe ensure that whenever we release one of
these 4 jars, we release the whole bundle (commons-core) together too. Or we
could just get jjar/maven rocking... :-)

----- Original Message -----
From: "Ceki Gülcü" <>
To: <>
Sent: Friday, May 10, 2002 2:06 PM
Subject: Resisting the temptation

> Greetings to all,
> As most of you are probably aware, log4j version 1.2 final was released
> just a few hours ago. One of the important planned new features of
> log4j 1.3 is the capability to interpret configuration files (in XML)
> with tags that were unknown at compile time. In other words, we would
> like log4j to be able to learn about new tags dynamically. This
> probably similar to ANT's capability of learning new tasks.
> The commons-digester library offers the infrastructure to support such
> capability. In short, I think commons-digester has what log4j
> needs. However, commons-digester requires commons-collections,
> commons-beanutils and commons-logging. Here is short list of concerns
> in increasing order of importance:
> 1) That's log4j.jar plus 4 jars instead of just log4j.jar.
> 2) Commons-xxx depends on JDK 1.2 where as log4j runs with JDK 1.1.
> 3) Circular dependencies. Log4j depends on commons-digester, which
> depends on commons-logging which depends on log4j.
> Given this seemingly intractable concerns, I have asked Costin
> Manolache, Craig McClanahan and Scott Sanders to borrow the
> commons-digester code. They all graciously granted permission for the
> modification of their code and its inclusion in log4j.
> So what's problem you might ask?  Well, it seems rather wasteful to
> start a new code base while a perfectly good one exists already.  In
> other words, I am trying to resist the urge to start all over again.
> Concern number 1), that is the increase in the number of jars, is a fact
> of (modular) life. As for concern 2), log4j can enforce that the
> configuration capability requires JDK 1.2 while the rest remains JDK 1.1
> compatible. Concern 3) is the one I find most challenging. There are 3
> possible approaches:
> 1) commons-digester et al. drop the requirement for commons-logging.
> 2) log4j accepts to depend on commons-logging
> 3) some new innovative approach...
> Solution 1) is probably not acceptable to the commons community.
> Solution 2 is not acceptable to the log4j community.  Solution 3
> requires a fresh approach.  Can you please help us find a solution in
order to
> resist the temptation?
> TIA, Ceki
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do You Yahoo!?
Get your free address at

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

View raw message