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:
> 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? Why are those 15
> committers wrong?
> I'm -1 (veto) on this change.
> --- [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.