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