Serge Knystautas wrote: > > > 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.
All I was trying to say is that by adding Mailets to our core distribution that have dependencies on nascent software we are sort of 'blessing' it as good when it may be unsustainable, unstable or simply a dead end. Maybe we need a better way of introducing such stuff without impinging on the core lib directories. Your proposal is totally inline with what has been done historically, save that you bothered to ask before introducing a new dependency. I guess I'm particularly sensitive to this having just worked long and hard on a project to escape 'jar hell', where multiple add-ons had introduced multiple dependencies requiring .jars at different version levels and many .jars providing the same behaviour using different APIs. Not something James is guilty off. > 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)? I don't see how a single line can be drawn. Each user has their own requirements that they consider 'core'. So, we either follow our current practise and package everything that may be required, or evolve to another solution. Ideally, such a solution would add just the jars required for a particular deployment to the classpath. These jars might be manually downloaded as optional bundles or we could use the OSGi framework to do this automagically. For now, perhaps, rather than trying to define what is core, we define which Mailets are stable and classify the remainder as experimental. The former ship with the core distribution and the latter in a seperately downloadable bundle. This is similair to Stefano's suggestion. > 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? Hopefully the above suggestion will speed progress. We could use it as a mechanism to allow people to donate their own Mailets. Mailets which could be transitioned to the stable set once their utility and robustness was proven. What are your thoughts? Cheers, -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
