I like this one! I think we should sort out the meta, meta-meta,
meta-meta-meta confusion. I have the impression that lots of talk about
meta
models is really about models. Any model in UML that is not about UML, is
a
model, not a meta model.
Yes! Even beyondUML, *any* meta model is a model in the end ;-)
Actually, according to this definition, FUUT-je's tool model IS a meta
model.
Yes.
It is a model about itself, modeled in its own modeling language that
is not quite UML. Still, I think it is much more helpful for understanding
what this model is about, to think of it as a model of what the tool knows
about, modeled in something close enough to UML that anyone knowing UML
can
understand it. Since '-je' means: 'Java environment', the model contains
exactly those things that are helpful to generate Java code and anything
related (DDL for example or XML), nothing more, nothing less.
I am not in favor to make the tool model very generic, because it would
loose its applicability to its domain: generating Java applications. What
would be possible, is to use FUUT-jes tool factory capability to create a
meta-modeling tool. Or to create a series of specific tools. For example,
for my PHP/MySQL work, the FUUT-je models I made of the application have
only limited applicability. Maybe it would be better to create a specific
PHP tool (using FUUT-je to create it). Such a tool could very efficiently
generate code from templates. Velocity can easily be used as the template
engine for such an application, or else the FUUT-je template engine is
generic enough for this purpose too (with slightly more effort).
With the right generic tool model you can easily generate your Fuut-je tool.
I don't understand why Fuut-je - which as you say is Java specific, and
which has additional idiocyncracies that could be removed - should be at the
root of the tool ancestry. We should strive for good separation of concerns
between problem space and solution space. The dependencies on the target
language (Java in this case) should be kept in template code as far as
possible, rather than in the structure of the model from which you generate.
See my other email. Starting from one meta model of a DSL expressed in some
tool model, you may want to generate multiple modelling tools for the DSL.
One such modelling tool *may be* implemented in Java.
Jorn
Jorn Bettin
jorn.bettin@xxxxxxxxxxxxxxxx
www.softmetaware.com
Tel +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534
_______________________________________________
gmt-dev mailing list
gmt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/gmt-dev