Jon Stevens wrote:
>
> Shame on Struts for not using Turbine's Connection pool. That makes
> me very upset because this was something that Craig promised would
> not happen (that there wouldn't be much major duplication in Struts
> as in Turbine).
>
> Even Cocoon uses Turbine's Connection pool and we put a lot of effort
> into making a build target for Turbine that allows you to only build
> the turbine-pool.jar.
Not so fast.
Cocoon1 uses a back level version of Turbine's Connection pool. An
incompatible interface change was made in Turbine, and they have not kept
up. See:
http://oss.software.ibm.com/developerworks/opensource/jakarta/proto35/xml-cocoon.html
Cocoon2 does not use Turbine's Connection Pool. Take a peek at:
http://xml.apache.org/websrc/cvsweb.cgi/~checkout~/xml-cocoon/src/org/apache/cocoon/components/datasource/Attic/JdbcConnectionPool.java?rev=1.1.2.5&content-type=text/plain
I'm not sure why there isn't more reuse going on within Jakarta, but my
_theory_ is that the cost associated with versioning issues exceed the
costs associated with dual maintenance.
Interfaces need to be deprecated for a period of time before they are
removed. This applies even to the simple movement of a constant from one
class to another. See:
http://oss.software.ibm.com/developerworks/opensource/jakarta/proto35/jetspeed.html
Consumers of these interfaces need to take deprecation warning seriously.
Without some attention to versioning issues, any CPAN initiative would be
doomed.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
