RE: [gmt-dev] evolving GMT in a fully open process that allows others to

["Ghica van Emde Boas" <emdeboas@xxxxxxxxxxxx>]

Again, I would like to make a point about Velocity here.
Velocity has a very reasonable template-editor plugin for Eclipse. Color
coding, delimiting if-then-else blocks etc. included. Only if your target
language happens to be PHP, the plugin is somtimes confused because the two
syntaxes are very similar. :-(

The other good thing is that Velocity can generate code/text from anything
Java. It can look at any object that you pass to a template and execute any
method on it. Therefore, if your argument to the template happens to be a
model or metamodel, or some other object structure that happens to be your
domain  model, then Velocity can use it. Writing good templates is a
completely different story of course :-)

Regards,
Ghica van Emde Boas
Bronstee.com Software & Services b.v.
e-mail: emdeboas@xxxxxxxxxxxx,
tel: +31 23 5474422,
or: +31 6 53368747 (mobile)
fax: +31 23 5473347


> -----Original Message-----
> From: Jorn Bettin [mailto:jorn.bettin@xxxxxxxxxxxxxxxx]
> Sent: Monday, March 22, 2004 9:14 PM
> To: Markus Völter; Thomas Stahl
> Cc: Jürgen Rühle; Markus Voelter; Ghica van Emde Boas; Jeff Hoare
> Subject: Re: [gmt-dev] evolving GMT in a fully open process that allows
> others to join the effort
>
>
> Hi Markus,
>
> > > Both Fuutje and architectureware provide model-driven
> template language
> > > based generation. We should consider the possibility of
> > > consolidation/rationalisation at that level to free up time and
> resources
> > to
> > > work on the GMT platform. I.e. I think it does not make sense to
> continue
> > to
> > > develop two template engines in parallel. For that consolidation to
> happen
> > > we need *solid* documentation of both the Fuutje and the
> architectureware
> > > design.
> >
> > yep - and this is why I proposed the feature matrix in
> > my other mail....
>
> Yes a feature matrix will help. However, as you have pointed out yourself,
> documentation of the internal design is even more important. The
> Case Study
> may provide much of that for openArchitectureWare, still have to read it.
> Nevertheless I'd like similar documentation on the table for
> Fuutje. Then we
> can have a knowledgeable discussion about how to best take the design
> forward.
>
> Our pattern collection will be very helpful because it also contains some
> information about further tools such as LANSA, eGen (Gentastic), and
> Codagen. Having designed the inside of LANSA RUOM, and having worked with
> all the other tools listed except for openArchitectureWare (which
> I'll have
> to get round to;-) there are some obvious patterns emerging as to what is
> important from a tool users perspective, and also as to what design
> characteristics make for an elegant (by that I mean covering all the
> "ilities") internal tool design.
>
> Beyond the patterns (which by definition we've seen in multiple places),
> there are specific strengths of individual tools that are fairly obvious,
> from which we can extrapolate further best practices. Examples:
>
> 1. (I have yet to see the openArchitectureWare template editor;-) Codagen
> has a very good template editor, and provides a good template debugger. A
> lot of best practices to pick up here. On the downside this tool provides
> only stereotype/tagged value based meta modelling, and no possibility
> checking of architectural constraints at application design time
> - but there
> our open source tools are already ahead ;-)
>
> 2. Gentastic provides fairly good visual meta modelling
> capability via UML,
> and has a neat way of linking templates. Again some ideas to potentially
> leverage. On the other hand the modelling tools generated from domain
> specific meta models are fairly clunky - but again here we can easily do
> better.
>
> 3. Because LANSA RUOM comes from an era where processors were slower, and
> regeneration was much more costly, we equipped it with the best impact
> analysis that I've ever come across. I.e. we only regenerated what *had to
> be* regenerated, which often is much less than the entire code base. RUOM
> tracked model changes with 100% reliability. As the user you
> never needed to
> select the parts of the model you wanted to regenerate code, RUOM
> "knew it"
> better than you as the user. Even these days, this type of change tracking
> is very handy - for example for intelligent version management of
> transformations and variants. RUOM provided excellent means to manage
> variants of code and for weaving together generated and hand crafted code.
> Least but not last, RUOM provided something that's best described as a
> "build control centre", with very convenient functionality to run
> builds and
> to fix any problems occuring during builds.
>
> > > The GMT platform can play a very important role. By allowing
> mix-and-match
> > > of various transformation/generation components it should allow people
> to
> > > make use of new transformers and generators without having to worry
> about
> > > rewriting all their existing transformations/templates - provided that
> the
> > > old generators can be extended into a GMT plug-in. Therefore building
> GMT
> > > plug-ins needs to be made as elegant and easy-to-learn as possible.
> >
> > yes. and we need some kind of repository, right? Are there any plans?
>
> Repository for what? I presume for models and transformations?
>
> > > How far can we leverage the Eclipse plug-in architecture for this
> purpose?
> > > What do we need to add/subtract from it to meet our needs?
> >
> > If binding to the Eclipse tool is ok, it is perfectly suited.
> > It is general and powerful enough so that we don't have
> > to adapt anything.
>
> Cool!
>
> > > Suggest that we are not religious but pragmatic, i.e. we should avoid
> > > reinventing infrastructure that has nothing to do with model
> > > transformation/generation.
> >
> > ähm, yes :-)
> >
> Good, I'd say that decides the plug-in architecture ;-)
>
> Jorn
>
>
> --
> This message has been scanned for viruses and dangerous content
> by MoveNext MailScanner, and is believed to be clean.
>
>