Hi,
Torque is has now been completely separated. If you look at the
jakarta-turbine-torque module you will see that the package structure
has been left the same to cause as few problems as possible.
The package structure should be cleaned up and we should define
an API for Torque in the same fashion as we are doing for Turbine.
I think the following should be done as well:
1) Separate the connection pool and make it pluggable
so that torque can easily be integrated into other application
that already use PoolMan, or the commons connection pool, or
the struts connection pool or whatever
2) XML an configuration
3) Use the digester to turn the datamodel into an object and
get rid of the dependency on xerces. It would be nice to
use the digester with MinML so that the distribution can
be tiny
4) Get rid of the Log wrapper in all the code and use the log4j
Category c = Category.getInstance(classname) method so
that torque can easily be integrated into other apps. Either
log4j or the logging API will dominate and I'm going to take
log4j. But as Ceki has noted they are so similar it is very
easy to change from one to the other
5) Some analysis on what we actually have would be prudent. Torque
is somewhat based on the work of Scott Ambler and I would like
to know where it is the same and where it diverges so we know
what we're dealing with.
Everything seems to working in the TDK which is still the only place
I really test torque but if others want to try some stand-alone
examples that would be great. I'll put the 5 items above in the
notes file in the jakarta-turbine-torque repository.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
