> -----Original Message----- > From: Chad Woolley [mailto:[EMAIL PROTECTED] > Sent: 26 March 2004 05:18 > To: [EMAIL PROTECTED] > Subject: Re: Cactus redux > > Vincent Massol wrote: > > Hi, > > > > There are several pieces of code that are located in the Cactus project > > (namely in our Ant integration module) and which could be useful to > > others independently of the Cactus context: > > > > 1- an API to manipulate the web.xml deployment descriptor (read and > > write). > > 2- an API to start/stop containers > > 3- an API to create container configuration > > > > - API 1 is useful to any container writer in particular. Thus I believe > > containers like Geronimo must probably already have such an API. I'll > > ask on the Geronimo mailing list to check it out. If they do, and if > > this API is nicely packaged in a thin jar (a jar used to manipulate > > servlet deployment descriptors for example), would you be ok to have > > Cactus Ant integration depend on it? > > > I'm all about code reuse too, but I'd say this should be considered > carefully. > In other words, they should be truly "thin" jars - no indirect > dependencies on > other jars (that aren't already required by Cactus). This can cause > dependency > bloat and be a pain for users of the framework, especially if some future > upgrade to these dependent jars causes some unexpected incompatibility.
Yep. This is the case, except for an XML parser (for those not using JDK 1.4) but that should be ok. > > I'm basing this on my experience. In my project (also a framework), I > thought > it would be cool to use Jakarta commons Digester to parse my XML config > file. > This added 4 or so jars to my runtime classpath, and I decided in the end > to > just write my own self-contained parser - especially since I couldn't get > Digester to work correctly anyway :) It's fine. It all depends on your needs and your setup. If you're writing a framework, sure you may not want to depend too much on external jars as it makes it more difficult for end users (thus the jars you are depending upon must really bring user value). However for applications, it's usually fine as application can bundle lots of jars without it being a problem (except for size but that's usually ok nowadays). > > > - For 2 and 3, what would you think about creating a Jakarta Commons > > project/a Codehaus project or possibly a Geronimo subproject for that? > > It could be called something like "Container Client Interface" (CCI). > > I'm not sure yet how much time I'll have for this but I'd like to know > > what you think so that we have some direction on what we'd like to > > achieve. > > Same deal, just consider the impact on the users of adding two additional > jars > to the runtime classpath (I assume they would be needed at runtime). Too > many > required jars can turn some people off to using a framework. Yes, but that would be up to the users to decide. They will either be able to leverage these jars or re-code it themselves. That said this CCI stuff is mostly for end usage stuff so it shouldn't be an issue. > > Just some thoughts... > Thanks! -Vincent > Thanks, > Chad > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
