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.
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 :)
> - 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.
Just some thoughts...
Thanks, Chad
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
