Hello all- I am currently re-working our development environment to bring us up to date with the latest and greatest features of jakarta-turbine-(2|torque|maven). One of the big problems that I am having is deciding how to handle the following situation:
There are a few key classes in the gray area between Torque and Turbine. Most notably, DBConnection, Criteria, and StringKey (these are the ones I have run into so far) that exist in both modules. The existing Turbine API's use the Turbine versions of the crossover classes. My question is, what should I do with my code that uses these classes? The options that I see before me are as follows: 1) Continue as I was, using the coupled version of Torque to generate OR mapping classes with all of the Turbine versions of the crossover classes. 2) Generate OR mappings using stand-alone torque and change the templates to point to the Turbine versions of the crossover classes. 3) Generate OR mappings using stand-alone torque with no changes to the templates and change the Turbine code to use the Torque versions of the crossover classes. 4) Use Torque versions wherever I can, and use the Turbine versions wherever I am forced to in order to comply with the Turbine APIs. This means that I have a connection pool in Turbine and one in Torque, which works but seems nasty. The main problem that I am having right is with the ValueParser.setProperties() API, which as you know uses reflection to figure out what properties to set based on the values in the value parser. I get an exception becuase I pass in a stand-alone Torque generated OR class whose id attribute is of type org.apache.torque.om.StringKey, while the BaseValueParser only knows how to manage org.apache.turbine.om.StringKey. Again, the options are pretty clear but I am interested in hearing if others have run into this and what is the best strategy for working around it in the interim. Also, I am interested in hearing how the developers will be handling this going forward - will the value parser classes be dependent on Torque? Will there always be a turbine version of these crossover classes? Or will the value parsing functionality be factored out of the Turbine classes and put in a common package so that Turbine is not dependent on Torque? -B -- Brian Lawler -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
