I'm not sure what your proposed or actual tool does, and I haven't used middlegen personally, so I can just try to describe what I know about.
The guy who started the jdo xdoclet module says he either has or is close to having jdo support in middlegen ( I think but am not sure that he is a middlegen committer) The jdo task in xdoclet generates all spec-required elements from marked up source files. There might be bugs, but I used it to generate metadata for a project with maybe 50 classes used with LiDO. Adding vendor-specific tag support should be very easy. xdocletgui is a pretty neat project that takes xml metadata files describing the tags for xdoclet tasks (ejb, jdo, jmx, ...) and assists you in adding tags to your source code. You load the source, it shows you a tree of the elements of your class (parsed from source), and the choices you have for tags to add. You can add fairly sophisticated rules about what tags are allowed where. xdoclet gui can be used standalone, there is also a jedit plugin. I think at least one other plugin (for idea?) is being written. At least one person is working on a project to generate marked up source code from argouml/poseidon/xmi. This was mentioned on the xdoclet lists but I haven't kept track of its progress. For ojb, I would strongly consider working on a bidirectional (xslt) migration path from jdo.metadata to/from repository.xml. I haven't studied the structure of repository.xml, but I imaging it must contain pretty much the same info as a complete jdo.metadata with all the defaults filled in. Something like this might encourage jdo users to consider ojb before the ojb jdo support is actually written, and it (in the other direction) could help ojb users that want in the future to use jdo contracts. Thanks david jencks On 2002.09.08 01:38:31 -0400 Ampie Barnard wrote: > Thanks for the useful pointers. No-one ever likes my square wheels anyway > :-). > > But it does seem like you are saying that a lot of the work for a tool > such > as the "Graphical tool for building Object / Relational mappings" in OJB > version 2, is already done in XDcolet and/or Middlegen? > > Ampie > > -----Original Message----- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: 07 September 2002 05:11 > To: OJB Users List > Subject: Re: A mapping workbench > > > Markup assistance is done in a metadata-driven manner by xdocletgui. I > suggest you study the unfortunately only partly documented capabilities > of > xdoclet before you reinvent too many wheels. > > david jencks > > On 2002.09.07 15:54:35 -0400 Ampie Barnard wrote: > > True, > > > > Regarding working from your source code - I am currently looking into > > writing a pluggable module for XDoclet that interprets the JavaDoc tags > I > > genereate from Middlegen. This should allow one to to modify the > mapping > > in > > the Java source to generate a more accurate repository.xml. Generating > > the > > ddl is a nice idea. One should be able to generate Torque templates > from > > the > > source code as well and then one can create the tables in the platform > of > > your choice. Schema migration does become problematic though - what > > happens > > to the existing data? > > > > Maybe a mapping workbench should simply modify the tags in existing > > Javacode. This would help the novice to do the mapping through a gui > > tool, > > but also allow the the expert to code the mapping mannually. But I > don't > > think Middlegen is quite there, although maybe they might be open to > the > > idea... Maybe we should ask them? > > > > > > > > -----Original Message----- > > From: Michael [mailto:[EMAIL PROTECTED]] > > Sent: 07 September 2002 09:34 > > To: OJB Users List > > Subject: RE: A mapping workbench > > > > > > From what I saw of MiddleGen it started with the database. I'm working > > on a > > new project and right now I'm designing our object model without even > > thinking about the database. What I'd really like is a tool that could > > generate the repository.xml file from my java objects. If it could > also > > create the database schema that'd be great (but if not I could do it by > > hand > > I guess). > > > > This is one part of EJB Entities I actually liked. I defined my > entities > > and didn't even think about the database schema. > > > > Michael > > > > > -----Original Message----- > > > From: Ampie Barnard [mailto:[EMAIL PROTECTED]] > > > Sent: Saturday, September 07, 2002 9:35 PM > > > To: OJB Users List > > > Subject: A mapping workbench > > > > > > > > > Just an idea... > > > > > > I recently started playing with Middlegen (available on SourceForge). > > Its > > > latest cvs version has a very well designed plugin architecture. It > > also > > > comes with a GUI for visual mapping of your plugin constructs (like > JDO > > > classes) to tables and relationships. It was originally written > > > to generate > > > the tons of code required to make entity beans work, but it took > > > me exactly > > > 2 days to write a plugin that generates most of the elements of the > > > repository.xml. Currently Middlegen's mechanism is one-way: it just > > > generates java code/xml. > > > > > > Now here is the idea... Why not co-oporate with the Middlegen guys to > > > implement the future version of the OJB mapping tool? I know the OJB > > guys > > > have probably already written the code for ReverseDB, so maybe its a > > bad > > > idea. (I have not been able to assess ReverseDB, since I can't seem > to > > get > > > it working on MySQL.) But I also do believe that this could be a > > mutually > > > beneficial relationship. > > > > > > Would love to hear your ideas on this. > > > > > > Ampie > > > > > > > > > > > > -- > > > 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]> > > > > > > -- > > 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]> > > > -- > 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]>
