Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » M2T (model-to-text transformation) » Any way to generate only one file?
Any way to generate only one file? [message #515007] Wed, 17 February 2010 13:39 Go to next message
Erik Sandin is currently offline Erik Sandin
Messages: 4
Registered: January 2010
Junior Member
Is there any way to generate only files that have been modified?

Scenario:

  1. I do a JET transformation using an input model. This creates a project and all files defined in main.jet. So far so good...
  2. Then I do a small change in one file and I want to just regenerate the effected file rather than regenerating the whole project.

Is there any way for me to accomplish what I want or do I have to generate the whole project every time?

Re: Any way to generate only one file? [message #515028 is a reply to message #515007] Wed, 17 February 2010 14:16 Go to previous messageGo to next message
Paul Elder is currently offline Paul Elder
Messages: 849
Registered: July 2009
Senior Member
Non-JET-users:

Read on, this isn't really JET specific. I've tagged the JET specific
paragraphs with [JET] - you can skip those.

Erik:

[JET] JET tries to be as efficient as possible when regenerating, so
that you don't have to make an investment in incremental building.

[JET] The main strategy is to verify that a file truly has changed
before writing it. While this incurs an extra read, this is typically
much cheaper than doing an unnecessary write. The savings is not only
from avoided I/O, you also get to avoid triggering Eclipse workspace
listeners and builders that may activate as part of a write.

[JET] To see this in action, run your JET transformation twice without
any intervening model changes. The second time through, the execution
log should contain no messages about file writes, unless your templates
inject things like timestamps into the output.


If you find that full re-build style executions are too expensive, you
would have to develop some mechanism for detecting incremental change in
the input model. I haven't really thought about this in detail, but
something like the following would work:

1) identify at the level in your input model at which you want to track
change
2) calculate some sort of hash code/signature on those elements
3) have the transformation write those hash codes (to a file) as part of
each execution
4) as part of each execution, compare current hash code values with
those saved in step 3 (from a previous execution), and flag the elements
that require regeneration
5) conditionally generate based on the calculation in step 4.

The hard part, by far, is deciding on an effective hash code/signature.
This requires actual THINKING ;-) . At a minimum, it should incorporate
all contained data/attributes. But, it may also need to include
referenced objects, as these may effect generated output, too.

I know all of this is possible, but I don't know of anyone who has done
it. (I may just lead a sheltered life.) I find the idea intriguing
enough to consider doing some experiments, but I'd be curious what
current experience is.

* Is anyone interested in doing incremental builds with code generators
like JET, XPand or Acceleo?
* Is anyone actually doing such builds? If so, how do you detect change?
* How many files are you writing (in a full build)?
* How big is your model (especially in terms of model elements that
would require signatures)?
* How long does it take to update a single file?

Paul
Re: Any way to generate only one file? [message #515200 is a reply to message #515028] Thu, 18 February 2010 07:11 Go to previous message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1769
Registered: July 2009
Senior Member
Hi Paul,

Paul Elder schrieb:
> * Is anyone actually doing such builds? If so, how do you detect change?
Achim Demelt has added support for incremental generation to Xpand.
1) it creates a trace between the model and the generator statements.
2) it creates a copy of the model
3) when doing incremental generation a diff between the last model state
and the current one is created (using EMFCompare). When a file should be
opened the old call graph (trace) is analyzed and it is decided whether
the diff contains any changes which have effect on the file to be
generated. If not the file is not generated and the corresponding code
is not executed.
This works pretty well as long as you don't call out to Java code.
Because that is not traced.

I haven't yet tried it out myself, but I saw some measurements which
look impressive.

Cheers,
Sven


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Previous Topic:Problem with XPAND2 generator after migration to mwe
Next Topic:MWE
Goto Forum:
  


Current Time: Sat Oct 25 08:04:30 GMT 2014

Powered by FUDForum. Page generated in 0.01596 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software