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] http://marc.theaimsgroup.com/?t=108004833700001&r=1&w=2 --- [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. >
