(Sorry for the delay, I've been on green holidays again).
On 24.03.2004 03:11:16 Glen Mazza wrote:
Team,
The Cocoon project is starting to move away from
Avalon. Their building on stone email thread today
[1], deals with the need to build Cocoon on a solid
framework they have control
Jeremias Maerki wrote:
-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
I'm not sticking to Avalon. All I can say is that I've successfully used
Avalon to build a flexible server for document processing using the ECM
container (same that Cocoon is currently using). I loved to work with it,
especially after I was able to rewire the whole application at a
customer's
Glen Mazza wrote:
Team,
The Cocoon project is starting to move away from
Avalon. Their building on stone email thread today
[1], deals with the need to build Cocoon on a solid
framework they have control over, and not on the
framework of another team that is apparently suffering
from high
Glen Mazza wrote:
snip/
Accordingly, I think it's time now for us to do the
same for FOP. I'd like us to drop the Avalon library
for 1.0, and switch to Jakarta Commons-Logging [4] as
a replacement for Avalon's logging component. For
1.0, I propose having FOP join Batik, Xalan, Xerces,
Team,
The Cocoon project is starting to move away from
Avalon. Their building on stone email thread today
[1], deals with the need to build Cocoon on a solid
framework they have control over, and not on the
framework of another team that is apparently suffering
from high turnover [2]). Cocoon
