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 site
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 can
(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 con
Glen Mazza wrote:
Thoughts? Votes?
-0 (not a veto)
J.Pietschmann
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 turno
Glen Mazza wrote:
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,
AntennaHouse,
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
