> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Ara
> Abrahamian
> Sent: 12. juli 2002 16:12
> To: 'Matthias Bohlen'; [EMAIL PROTECTED]
> Subject: RE: [Xdoclet-user] UML modeling frontend for XDoclet
>
>
> Haven't tested it yet but it indeed is very interesting. Keep up the
> good work pal :-) I will probably ask our analyst/designer guy to use it
> and let you know how he feels about it.
>
> Anyway the release bundle doesn't look complete: it lacks the required
> jars, a sample, and docs.
>
> PS: Ideally I would like to see convergence of UML2EJB and Middlegen.
> Imho middlegen's architecture should be extended to treat UML as yet
> another input source. What do you think? Aslak?
>
You're reading my mind, Ara. There are pros and cons of course. Both UML2EJB
and Middlegen use Velocity as template lenguage to spit out XDoclet
@annotated Bean implementations. Middlegen has a plugin architecture similar
to XDoclet, and the EJB output is part of the cmp20 plugin. Middlegen also
has a JDO plugin, and I'm currently working on a JSP/Struts plugin. -And
there is WebWork/Velocity up the road (using Velocity to generate Velocity
code!).
What Middlegen does is to build an object model out of the database, based
on information that is gathered reading database metadata. It's merely
transforming the iformation provided by a java.sql.DatabaseMetaData object
into objects that are easier to deal with: Both from velocity templates, but
also from the GUI which is part of Middlegen. These objects are basically
table, column and relation.
I have no knowledge of XMI whatsoever, and my UML knowledge is limited to
basic understanding (I can draw 4-5 of the diagram types on a blackboard).
If we were to see a synergy effect here, It would be to do as you say: Treat
XMI as an input source analogue to database metadata. That would require the
invention of a new abstraction layer between Velocity and the input sources,
so that the Velocity templates could be agnostic about the origin of the
data (whether it comes from a database, an XMI document, or perhaps even
other kinds of input sources).
Matthias, do you think such an abstraction layer would be feasible? -Or
would this common denominator be too narrow to capture the detail level
provided by the two input sources we're talking about here? We're facing the
same kind of problems that the designers of good-old AWT must have been
facing: Come up with an API that can serve as an abstraction layer between
Motif, Windows, Mac and other windowing systems.
I think XMI and database metadata can provide much of the same information,
but still, each of them probably provide information that the other doesn't.
I don't know for example if XMI can express whether a class field
corresponds to a foreign key in a database column (this knowledge is
required if we want to generate CMR EJBs for example). I don't know what
kind of information XMI provides that database metadata doesn't, but I'm
sure it's a lot.
I'm looking forward to reading your repsonse on this.
/Aslak
> Ara.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:xdoclet-user-
> > [EMAIL PROTECTED]] On Behalf Of Matthias Bohlen
> > Sent: Friday, July 12, 2002 11:50 AM
> > To: [EMAIL PROTECTED]
> > Subject: [Xdoclet-user] UML modeling frontend for XDoclet
> >
> > Hello, everyone,
> >
> > this week, I have completed the development of an open source code
> > generator
> > that takes a Unified Modeling Language (UML) model from a CASE-tool in
> XML
> > Metadata Interchange (XMI) format and generates Enterprise JavaBeans
> > classes
> > with XDoclet tags as output. The associations between classes in the
> model
> > are automatically transformed into @tags for EJB CMR. You will get
> EJBs
> > that
> > can readily be deployed into JBoss and others.
> >
> > The code generator is called UML2EJB and is released on SourceForge
> under
> > the GNU Public License. It has been tested with the Poseidon CASE tool
> > (see
> > www.gentleware.com) but should work with any CASE tool that can write
> XMI
> > output.
> >
> > Features:
> > * Import of XMI from the CASE tool into the generator.
> > * Builds an object model that drives the Jakarta Velocity template
> > processor.
> > * Templates for Session Beans and Entity Beans included.
> > * Automatic use of J2EE patterns inside the generated beans.
> > * All fully customizable to the needs of your project.
> > * Uses XDoclet as a solid foundation to generate all the EJB-related
> > files.
> > * Graphical modeling easier than writing @tags.
> >
> > Environment:
> > * Integrates into an Ant script as a custom task.
> > * Integrates with CASE tools that write XMI format,
> > i.e. Poseidon, TogetherJ, Rational Rose.
> > * Adaptable to different XMI dialects via XSL input transformation.
> >
> > Plus:
> > * Documented on the project website at http://uml2ejb.sourceforge.net
> >
> > I am currently looking for volunteers who want to test it.
> > Matthias Bohlen
> > http://www.mbohlen.de/
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Gadgets, caffeine, t-shirts, fun stuff.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Xdoclet-user mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/xdoclet-user
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Gadgets, caffeine, t-shirts, fun stuff.
> http://thinkgeek.com/sf
> _______________________________________________
> Xdoclet-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-user
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Gadgets, caffeine, t-shirts, fun stuff.
http://thinkgeek.com/sf
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
