Hi Stephen, > >>OJB is not considered a replacement/successor to torque. It is an >>alternative. >
In my eyes it's not torque vs. OJB. Torque is good at reverse engineering a legacy DB. torque is very good at generating all needed stuff from an xml schema. (In fact we are using Torque to generate the OJB testbed database!) OJB is good at "classical" O/R features. It is similar to TopLink in many ways. The best thing about OJB in my eyes is that it supports multiple APIs for Object persistence (ODMG, JDO, and our Kernel APIs PB and OTM) and that it is highly configurable and pluggable. OJB must improve it's forward and reverse engineering capabilities. I think that's a point where both projects could come together. > > A few days ago I would have been in complete agreement with you. But I'm > starting to have hesitations. > > I've yet to take a good look at OJB (e.g. run some samples, browse the > source, etc.), so in the midst of the torque > v4/db.apache.org/commons-sql ruminations, I felt I've had a na�ve bias > when it came the OJB/Torque issue. > > I really like what Torque does. I don't like how it does it. I think for > Torque to become a successful project in and of itself rather than a > Turbine tag along, it needs a cleaner, more robust implementation, > better test suites, etc. that I've been tentatively slating for v4. > > What I want to avoid is getting my v4 blinders on and be completely > ignorant about what could be a perfectly good implementation already > here at Apache. Investing significant developer time in the duplication > of an existing project hurts developers and users alike. > > Basically, I realize I have self-interest in seeing Torque succeed, and > don't want that to taint objectively determining the future of Torque > (e.g. whether there is one or not). > > Given that OJB and Torque do more or less the same thing (correct?), > making object persistence transparent, I think in the long run having > two implementations around would hurt both projects (having separate > user bases, resolving the same problems, etc.). > > For example, take ORO and Regexp. I don't know the politics of why > Jakarta has two regexp implements, but in my newbie days I found it very > confusing. To me, if ORO works better than Regexp (at least that is what > the ORO index page insinuates...) they should have become one project > with ORO being a completely new version of Regexp. > > (I'd be interested in hearing what really happened with ORO and Regexp, > but I don't mean to start a long discussion on it, I'm just using it as > an example.) > > One could also use Struts and Turbine as Jakarta two projects with the > same purpose but separate implementations. Though for some reason this > seems okay, perhaps because they take drastically different > implementation routes, or perhaps because Struts and Turbine seem to > cater to different audiences. > > So maybe this is how OJB and Torque could be related. Though I think if > we're going to knowingly walk into such a relationship, from the start > we should have pretty good definitions of which audience each project > caters to. E.g. something that says "People looking for x should choose > OJB, people looking for y should choose Torque." > > Having two separate audiences would, in my mind, really justify keeping > Torque around and sinking some time into v4. > > (Btw, I also think this sort of audience comparison would be really > helpful for Struts and Turbine to have.) > > Going forward, I think what might be useful is to startup a discussion > on [EMAIL PROTECTED] (I think that was the list Martin mentioned the > other day) with the OJB guys and us Torque people, perhaps along with > some Apache higher-ups listening in, and really figure out what this > db.apache.org thing will entail. > > Of particular interest would be the technical features of OJB and Torque > and whether they are complementary or merely duplicates of each other. > Also, whether they could potentially be combined. > > (I'd mentioned before that OJB using reflection leaves a bad taste in my > mouth That's not correct! You can choose between 3 predefined access strategies 2 of them using reflection, the third using only java-beans compliant access. It is also possible to plugin user defined strategies! > so perhaps Torque could generate objects with an interface, say > OjbPersistanceSupport or something, that given a Map or however OJB goes > about things, would take the place of what ever OJB currently uses > reflection for.) > > (Also, a minor note, when considering dropping Torque for OJB as > Apache's sole object persistent framework, I don't mean all development > on Torque should stop. Of course for the user base, versions of the 3.x > line could keep being released with minor refactorings and bugs fixes. > It would just mean that the major refactoring I'm considering in Torque > v4 would not happen.) > > So, that's what I've been mulling over the past few days or so. It > should be an interesting few months (?...I don't quite know what the > time frame for such things as db.apache.org/torque v4/etc. are) to see > how this all plays out. > As mentioned above: IMO we should discuss if it is possible to combine Torque and OJB to build a first class O/R Tool with full fledged forward- and reverse-engineering support. cheers, Thomas > - Stephen > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
