> That's what the sandbox is for, no?
Um, no.
My goal here is two-fold:
First, to get a 1.0 release of httpclient out the door as soon as
reasonable. A 1.0 release of anything shouldn't depend on anything in the
sandbox, or anything not also released, it seems to me.
Second, to avoid duplicating this code in each commons component that uses
it. In particular, we *must* avoid using distinct packaging for this log
package in each component, otherwise the log stuff isn't interoperable
between components, and that's really the point isn't it?
To do this, I see two options:
1. Get the log4j folks to add a "logging abstraction" like this to the scope
of log4j, and to formally release it as a tiny, stand-alone JAR.
2. Repackage what is currently org.apache.commons.httpclient.log (or
something like it) as a stand-alone commons component
(org.apache.commons.log?), and formally release it so that it can be used by
other commons (and outside) components.
I think I'd prefer the former, but the later could be completed in a day or
two. Perhaps the appropriate strategy (given goal the first) is to do
option 2, and then work our way toward option 1.
Ceki, you're on the log4j team right? What do you think?
