> OJB must improve it's forward and reverse engineering capabilities. > I think that's a point where both projects could come together.
I'm slowing starting to agree. While it's a bit disappointing to see Torque, or some incarnation of it, being used only for forward/reverse generation and leaving all of the cool persistence stuff to OJB, my current view is that it is in the best interest of both projects. So, there are several options for Torque and OJB merging/working together. 1) Assuming Torque dumps it's om/peer generation stuff, it could, with some refactoring, be completely folded into OJB as it's forward/reverse generation tool and active development on Torque would cease (save perhaps for bug fixes to the 3.x line). 2) Torque could also dump its om/peer generation stuff, but remain a separate project that focuses solely on a well-designed, generic forward/reverse generation framework that OJB could then extend/customize, ideally with little effort, for it's forward/reverse generation needs. Ideally, this would also allow other projects who want to do any sort of DB forward/reverse generation to build their functionality on top of Torque. 3) Torque's sql forward/reverse generation functionality could be moved to a separate project, something like commons-sql, which really would probably be exactly like option 2, except without the Torque name. Torque would then build itself on top of this commons-sql project to do the om/peer generation it currently does now. >From a loyalty to Torque perspective, I like the 3rd option. I think we could build a much cleaner om/peer generation architecture, especially if a well designed commons-sql framework was available. However, then we're still competing with OJB. However, I think the 2nd option makes more sense in the long term. Existing Torque users will be kind of miffed, but I think having one solid implementation of object persistence framework is best. I also think OJB should be kept purely an object persistence framework; any sort of forward/reverse generation should be in a separate project. I think the forward/reverse generation stuff would be better designed and implemented with its own set of committers that are interested solely in it. (Currently in Torque, the forward/reverse generation stuff is a lower priority than the Torque core, and I think this would tend to be the case in OJB, too). Which option do you (and perhaps what OJB people in general) like, Thomas? Which option do the other Torque devs like? Also, if we really want to keep both OJB and Torque around, I think they should at least have different audiences (or groups of users each project targets). Doing the same thing or the same people in different projects is silly. Does the different audiences thing make sense? If it does, can we come up with two valid different audiences? E.g. OJB is for app servers and Torque is for servlets (I know, that's completely made up and completely untrue...I just couldn't think of a better example). I dunno, without separate audiences, or separate reasons, for each project existing, I have a hard time justifying keeping Torque's om/peer generation around (if either project were to be dropped, I'd have to assume it's Torque as I think it's way further behind, both implementation-wise and architecture-wise, OJB). Perhaps if Torque morphs into mainly a forward/reverse generation project, the existing om/peer stuff could be kept around for legacy support and perhaps with the notion of future refactoring, but then it still comes out doing the same thing as OJB. > 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! Very cool. Sorry for my un-informed assumption. - Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
