J. Matthew Pryor <[EMAIL PROTECTED]> wrote on Monday, July 15, 2002 8:59 AM
> JMI is a Java "binding" of the OMGs Meta Object Facility (MAF)... > NSMDF ... is a (partially?) JMI compliant? tool ... > NSUML is an API for reading, writing and generally working with a UML > models, where the model will be read & written in the XML Meta-data > Interchange format (XMI). > So far, these are all complimentary with UML2EJB, except for the > fact that at present, UML2EJB uses XSLT to transform the UML/XMI > file into an intermediate format (SimpleOO) and then uses JAXB > generated APIs (based on the SimpleOO.DTD) to work with the > SimpleOO format files for further template based code > generation. > It certainly would be possible to replace the XSLT step and the > SimplOO format file with a UML/XMI file and API (such as NSUML), > and given that there are several Java standards relevant here > (namely JMI and JSR 26 the EJB profile for UML, that might be a > good idea IMO). However the devil is in the details b/c the > exported XMI from different tools does vary a lot. Yes, Matthew, that was precisely the reason that I have deliberately ignored NSUML which I already knew because the Poseidon product uses it. Some time ago, I have tried to import TogetherJ XMI into Rational Rose - no success. I compared the XMI formats that the tools use and found out that they are speaking two different dialects. The situation is like one is talking "Cockney", the other is talking "US midwest". Ara Abrahamian <[EMAIL PROTECTED]> wrote on 15.07.2002, 19:24:51: > - JMI/XMI/whatever xml format can be used as the entry point into > uml2ejb to generate the output. The big questions are: > > - Is xmi enough/ok for describing a database metadata too? After > all xmi is good at describing an OO model, not a database. Can it handle > more sophisticated cases (such as multiple table -> on class mapping, or > other weird settings)? I feel like it's not flexible enough for database > metadata or stuff like those, and please don't make the simple > assumption that table->class, column->field and so on. They really are > two different beasts. Ara, you're absolutely right. And my additional question is: Do we want UML2EJB do think about our weird way to use the IT world? My answer would be "no". If someone wants to talk to 3 tables with one class, he should do that with a BMP bean and write the SQL by hand. He should only write UML2EJB templates for that if (and only if) the situation occurs 90% of the time in his project. However: if this was the case in his project, I would ask him why. :-) > - If we really want a manageable system in uml2ejb we should > make it free of any logic or calculation or extra tricks, the model > generation part should take care of it: generate a model which can be > simply accessed by velocity templates and generate java (or maybe other) > sources. Then again that means xmi should have enough hooks for us to > put all those polished meta data info into. UML as well as XMI has stereotypes and tagged values. UML2EJB already writes tagged values on classes into the JavaDoc comments of the class declaration. This should be sufficient for a moderate set of tricks to play. CUAGN... Matthias ---------- Matthias Bohlen Consulting that helps project teams to succeed... http://www.mbohlen.de ------------------------------------------------------- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
