Hi Leo & Berin, > My own rationale for adopting Avalon was similar to your > basic points, with the difference that I didn't care much > for "other available services ready to use". But what I did > want was: > > + Good solid design patterns. > > + Configuration support. > > + Pluggable implementations of defined interfaces. > > + Unified logging. > > And Avalon Framework provided all that. I motivated > the decision with "Look, if we don't use Avalon, we > have to invent something precisely like it ourselves. > Let's go for it, and if it becomes a bother, fork. > That way, we may gain something, and we're sure not > to lose anything." > > And that pretty much worked. > > I'd emphasize the smallness of Framework and get people > going with that first - once they see how easy it is > to use (especially configuration - I *love* that package) > I think they'll accept it. Emphasize low-committment and > potentially huge gains.
thanks for your argumental help :) Regards, J�rg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
