> From: Schaible, J�rg [mailto:[EMAIL PROTECTED] > > Hi folks, > > the topic was not intended to start any flame wars, but I'll > face some team members with the > we-won't-depend-on-anyone-else's-code syndrom. > > My current basic points: > - principal and patterns described in DaW > - lifecycle management > - configuration capabilities (1) > - service for logging, instrumenting, pooling > - other available services ready to use(2)
Well, a hard-line "we-won't-depend-on-anyone-else's-code" is useless - you wouldn't be able to depend on Xerces, Java or anything else - so I assume that what we have here is a "let's keep dependencies to a minimum" argument. 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. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
