Log4j-CL-EL-JV.txt
<P>
Recently <A HREF="http://logging.apache.org/log4j/">log4j</A> removed some deprecated 
classes/methods. This after years of deprecation, seemed like it ought be trivial. 
This is what transpired...
</P><more/>
<P>
First, the next Gump run detected that <A HREF="http://jakarta.apache.org/commons/logging/">Commons Logging</A>, 
<A HREF="http://avalon.apache.org/excalibur/">Excalibur Logger</A>, 
and <A HREF="http://jakarta.apache.org/velocity/index.html">Jakarta Velocity</A>
were using API classes/methods that log4j considered deprecated. 
This 'took down' (stopped Gump run coverage to) roughly 250 dependee projects, a significant percentage of Gumpage.
<B>Things seemed straight-forward enough, the features had been clearly deprecated for two years, it was time to change them. So, update...</B>
</P>

<P>
Unfortunately, the [GUMP] prefix didn't match the [logging] prefix that the commons-dev list requests, so failed to pass filters & sat un-noticed for a while.
When enough (impatient) noise had been made, the situation was investigated & things were not so simple. 
</P>
<P>These issues took almost two weeks to resolve, some time lost, but much well spent on analysis/discussion/communication. Discussions occured on the commons, logging, avalon and velocity and gump lists, and ought be archived there. (This distribution might explain
some of the mis-communication that led to some time lag.)
<P>
<HR/>
<P>For each of the three projects directly affected...</P>
<P>
<B>Avalon</B>: Some things deprecated had not been marked as such, so they were immediately restored by log4j. This helped restore Avalon. What was noticed here
was that Gump pages obscured the build log (somewhat backwards since that is likely the key information) so a fix was attempted,
moving that nearer to the top of the page.
</P>
<P>
<B>Commons Logging</B>: There was no runtime compatible solution that could benefit from the two years of deprecation overlap that log4j had intended. A
few <A HREF="http://jakarta.apache.org/commons">"commoners"</A> found this. A few solutions were discussed, until log4j found an acceptible one, that
commons-logging agreed would be zero impact. Commons-Logging coded to this new solution, allowing a wide range of compatibility.
</P>
<P>
<B>Note:</B> Deprecation had been turned off in these builds, and some log4j deprecated things had not been marked deprecated. Deprecation warnings verbose,
it'd be nice if 'official' builds could have them on, but day to day builds off.
</P>
<P>
<B>Jakarta Velocity</B>: 
These folks had it easiest, changing one word from Priority to Level, but still the communications process could've been improved, and
feedback was taken.
</P>
<HR/>
<B>SUMMARY:</B> Deprecating classes is non-trival with Java (especially when trying to maintain them for years, and use sub-classing as aliasing). 
Deprecation <B>'overlap windows'</B> -- where a fix gets to be backwards compatible w/ a decent (most likely found) sub-set of previous releases -- are a
key aid. Managing these is invaluable. Deprecation only works when people work together and communicate. We still have some work to do to improve our
group understanding/knowledge of <A HREF="http://jakarta.apache.org/commons/releases/versioning.html">version numbering</A> and what contracts we
are making with them on each release.
</P>
<P>
<B>This work saved users of 250 projects from a little (perhaps big) bit of Jar Hell!</B> That is awesome work that will go largely unrecognized, but is still invaluable. Thanks to all involved...
</P>