On 4/22/06, Steve Brewin <[EMAIL PROTECTED]> wrote: > My concern wasn't really related to size. It was with creating a dependency > on a new and cool but not yet widely used API. In the same way as others > have expressed concern that we should not jump 'out of the fire in to the > frying pan' [old English] regarding Avalon versus the latest and greatest > container bandwagon, I was trying to say the same about Hessian versus RPC. > > If there is a size issue, we could try and differentiate between core and > optional mailets and produce a core distribution plus one or more optional > Mailet packs. Its a common approach. Many projects do this splitting by > their own criteria, such as Xerces core and tools.
I agree with the point of core James not quickly adding new dependencies. I don't consider Avalon analogous to a mailet because Avalon affects the core code, while a mailet is a standalone optional class. Where do we draw the line for non-core dependencies? We already bundle... - ClamAV (no java dependency, but 3rd party dependency) - S/MIME (bouncy castle java dependency) Do we only support dependencies when they are a very core part of SMTP handling (which I would categorize as those 2 dependencies)? My 2 cents is that we should look at what Cocoon, Ant, and Spring have done where they added support for lots of external dependencies to enable adoption of their platform. Certainly it would be nice to have this as a separate build so that the jar with the optional mailets/matchers and their depencies are separate, but so long as the code is properly independent, why stop progress? -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
