-0 (I don't feel I'm in a position to veto) for now as long as you're only talking about the logging aspect. FOP needs a few things more, as does Cocoon. Simply dropping Avalon doesn't help. If you look at http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization you can see that logging is only one item in the requirements list we put together.
Jeremias, I reached your conclusion yesterday in doing the logging conversion (I'm only 2/3rds there right now): namely, to keep Avalon for the time being for the non-logging components, but just to replace its logging component with Commons-Logging. It was just in doing the conversion yesterday that I first noticed that we were using Avalon for other things (even after switching to C-L, it will still be in about 10-15 classes over a few packages), namely the configuration that you mention. I also agree in not switching away from the Avalon configuration unless there is something better in Commons--*** or something better we can do ourselves. I haven't studied configuration (hence am not very knowledgeable about it), and it is not among my priorities--other team members have thankfully been taking the lead on configuration.
Also, if there's another feature you like from Avalon, we can always use it. To me, Avalon is now just another library, like the Commons--*** libraries. It's just that FOP won't be living and breathing Avalon 24/7 anymore--we'll use certain parts of it where it's better than Commons--*** libraries, but not just blindly using it "because it's Avalon". The entire 30-40 email Cocoon thread on "building on stone" was not much of a confidence builder in adopting the latter philosophy--email after email, the team had little good to say about Avalon as an application framework, and is now considering painful contortions [1] to liberate themselves from it.
Thanks, Glen
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108016162526312&w=2
