Sorry, I'm so used to using A-F Enums that I didn't think about that.
I've fixed this and hope that you can agree with my change now.

On 03.01.2005 14:51:00 Glen Mazza wrote:
> Jeremias,
> Would you please elaborate on the need for this?  I
> want to make sure that adding an additional dependency
> on the Avalon project is passing a cost-benefit
> analysis here.
> We're not a fluffy hi-level word processing system
> --we are a very low-level application (like a
> compiler), that is in turn will be integrated into
> other applications.  Therefore we have to be careful
> not to include gratuitous linkages to other libraries.
>  (That we already--currently--use Avalon for
> configuration does not excuse us from this principle. 
> Linkages should be kept at a minimum.  For example, we
> had an option of using Commons Configuration instead
> of Avalon.  Now, if we do so, we're still required to
> keep Avalon just because of your change below.)
> What is lost if we don't link to Avalon here?  How
> often have we failed by relying on Java variables? 
> How come Xalan and Xerces can work without Avalon
> variables but FOP can't?
> Also, why is the Cocoon Team in error for trying to
> detach themselves from Avalon[1]?  Why are those 15
> committers wrong?
> I'm -1 (veto) on this change.
> Glen
> [1]
> --- [EMAIL PROTECTED] wrote:
> >
> >   Made the LayoutDimension keys a subclass of Avalon
> > Framework's Enum to make the thing more
> > debugger-friendly and more type-safe.
> >   

Jeremias Maerki

Reply via email to