Hi Max!
Yes, I got the email, but my answer bounced back :(=20
Meantime I integrated the new hibernate3 alpha tools generator by using=20
hibernate ant tasks to generate DDL and hbm to java classes. Answering the=
=20
second question, java.tri uses Hibernate tools ant tasks to generate all=20
that could be generated that way :)
Now about EMF: I don't really love EMF framework, but it has one great=20
quality, it generates a plugin editor tree from a argo UML model. Then, I=
=20
can design different metamodels and my whole plugin will start working with=
=20
minimum effort, just because eclipse generates the new editors for me. And=
=20
instead of having a DTD I have an UML model to define the format of the=20
archives, it's much more powerful to express information in UML.
Of course that wizards are still hand writed. Therefore I use EMF to store=
=20
the specification of the system that is outside UML1.3 scope (the minimum=
=20
set). Also EMF is very good in managing and storing those specifications fo=
r=20
me, and I hope it can be detached from eclipse framework and used in other=
=20
frameworks.
I use too JMerge to code merging, but it's easy to put it stand alone=20
projects, and it's open source (EMF is too).
Now about what I don't use in EMF: I DON'T use the JET emmiters templating=
=20
and EMF code generators to generate code in the plugin. I use EMF to store=
=20
my metadata and generate part of the plugin that I distribute. The generato=
r=20
can be fired against any EMF specification, looking for a template in the=
=20
template directory. One of the key points here is to allow the user to=20
define new classes of metamodel objects (by regenarating the plugin in a ne=
w=20
UML model) and/or new templates to those objects in a easy way (you just=20
have to drop the template in a appropriate directory). Coding zero lines of=
=20
java.
Hibernate tools uses as metadata the HBM files that are rigid XML=20
specifications (or annotations now). That works fine now because the focus=
=20
of hibernate tools is to generate the hibernate code, and not build a=20
general propose code generator.
I could replace EMF if I could find (or develop) some swing based editor=20
that can store/read the metadata for me in a text format. But now I think=
=20
that would be easier to make EMF editors to work outside eclipse. But it ma=
y=20
be that I just don't know of a better solution, I'm very open minded to get=
=20
rid of EMF :-)
And that's another solution, I could make java.tri generates itself and=20
store meta-information using hibernate (is there a new XML instead of=20
relational database way to persist right?) :-)
Of course there is much eclipse code inside the plugin logic, but I can=20
easily refactor that.
I too have dependency on Netbeans MDR, I use it to read XMI models and save=
=20
in EMF format. That dependency is really strong a one, I don't know of othe=
r=20
product that can read XMI as this.=20
Why I save XMI in EMF format ? Because the user may edit the EMF in a=20
graphic way to specify ORM domain information (like to use VARCHAR(20) for=
=20
some String column) and some hints outside the hibernate HBM scope and=20
outside the UML class model scope. I think of my tool being used to other=
=20
ORM or EJB3 in the future.
I hope not being too confusing in my thoughts.
|
