search

joergreichert / spray

Automatically exported from code.google.com/p/spray
1 stars 2 forks source link

Integrate Xtext builder participants of DSLs with each other #187

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Currently the builder participants / generators of the different DSLs do know 
nothing about each other. So a change e.g. in the Style DSL that has no effect 
to references to style definitions in other DSLs may break the Java code basis 
as the generated Style Java code may not be compatible to the other generated 
Java code that uses this code. 

So it would be best practice to always trigger the generator for all DSL 
artifacts that are potentially affected by the change in a DSL artifact, e.g. 
the Shape generator is also invoked when a style has changed as a shape can 
reference a style.

scenarios:

1.  *.style file changed
1.1 style file contains only style definitions
    * (re-)generate the Java file for the style definition
    * if a style name has changed (or even deleted) this makes all elements dirty that references this style (as the reference should be broken then):
      * style definitions that have defined this style as super style
      * shape and connection definitions that references this style
      * mapping definitions in .spray files that references this style
    * if the style references a gradient that has been not generated yet in Java this generation should be triggered within this build
    * if the style references a super style that has been not generated yet in Java this generation should be triggered within this build
1.2 style file contains only gradient definitions
    * (re-)generate the Java file for the gradient definition
    * if a gradient name has changed (or even deleted) this makes all elements dirty that references this gradient (as the reference should be broken then):
      * style definitions that references this gradient
1.3 style file contains gradient and style definitions
    * apply first 1.2 and then 1.1 as styles may depend on existing Gradient Java files
2.  *.shape file changed
    * (re-)generate the Java file for the shape definition
    * if a shape name has changed (or even deleted) this makes all elements dirty that references this shape (as the reference should be broken then):
      * mapping definitions in .spray files that references this shape
    * if the shape references a style that has been not generated yet in Java this generation should be triggered within this build
3.  *.spray file changed
    * (re-)generate the Java files derived from the mapping definitions (i.e. all Graphiti feature classes as well as some more Graphiti related classes)
    * if in the Spray file a style is referenced that has been not generated yet in Java this generation should be triggered within this build
    * if in the Spray file a shape is referenced that has been not generated yet in Java this generation should be triggered within this build
4.  domain model changed
    * this should make Spray files dirty that references elements from the domain model
5.  Workspace start
    * it should be checked if there already Java files generated for .spray, .shape and .style files contained in a project if not so, the generation should be triggered (so it is not necessary to make existing files dirty or call explicitly clear project to trigger the generation) - this check could be done e.g. in the Activator class

Original issue reported on code.google.com by de.abg.r...@gmail.com on 14 Oct 2012 at 1:19

GoogleCodeExporter commented 9 years ago 
Sometimes the spray generator (for the .spray model file) is running ten times 
in a row. It only seems to happen for the spray file in the business domain 
project.
It happens when either the spray file itself is saved, or a spray file of 
another project. There are no other changes done in any other file.

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.styl
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.styl
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.shap
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.styl
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.spra
y

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.shap
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.styl
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.spra
y

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.shap
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.styl
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.spra
y

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.shap
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.styl
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.spra
y

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.shap
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.styl
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.spra
y

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.shap
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.styl
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.spra
y

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.shap
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.styl
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.spra
y

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.shap
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.styl
e

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.spra
y

Spray generating for model 
platform:/resource/org.eclipselabs.spray.examples.mydiagram/model/mydiagram.shap
e

Original comment by de.abg.r...@gmail.com on 4 Nov 2012 at 4:51

GoogleCodeExporter commented 9 years ago 
The above number of generator step happens after saving the style model. As the 
style model itself uses the generated Jav style files,  it can trigger itself 
in a loop.  We should avoid that some way.

Original comment by joswar...@gmail.com on 4 Nov 2012 at 6:25

GoogleCodeExporter commented 9 years ago 
To avoid loops in style dependencies we should have an Xtext rule in the style 
grammar like:
Style:
    {Style}
    "style" name=ID ("extends" (superStyle=JvmTypeReference | superStyleFromDsl=[Style]) )? "{"
       ("description" "=" description=STRING)?
       layout=StyleLayout
    "}";

instead of:
Style:
    {Style}
    "style" name=ID ("extends" superStyle=JvmTypeReference)? "{"
       ("description" "=" description=STRING)?
       layout=StyleLayout
    "}";
That way a style can either refer to a style in the DSL or to a Java style.

Original comment by joswar...@gmail.com on 4 Nov 2012 at 6:38