Use ImportUtil to manage imports in templates

[GoogleCodeExporter]

Templates contain sometimes a huge amount of logic to create the right imports. 
For example, FeatureProvider.xtend uses 50 lines of code just for computed 
imports.

{{{
...
    import «feature_package()».«diagram.name»Layout«cls.visibleName()»Feature; // 4
        «IF cls.representedBy instanceof Container»
            «var container = cls.representedBy as Container »
        «FOR MetaReference reference : container.parts.filter(typeof(MetaReference))  »
          «var references = cls.type.EAllReferences » 
          «val referenceName = reference.getName»
          «var target = references.findFirst(e|e.name == referenceName ) » 
          «IF ! target.EReferenceType.abstract»
    import «feature_package()».«cls.diagram.name»Create«cls.getName»«reference.getName»«target.EReferenceType.name»Feature;
  ...
}}}


Therefore there is the ImportUtil class, which uses an ImportManager to collect 
the qualified names of used classes, and prints out the simple name.

To use it, the body of a template must be evaluated first before printing out 
the imports. As a reference look at AddConnectionFeature.xtend, the mainFile() 
method initializes ImportUtil and delegates to mainFileBody to evaluate the 
file content and their imports.

Original issue reported on code.google.com by karsten....@googlemail.com on 23 Sep 2011 at 6:29

[GoogleCodeExporter]

The class XtendProperties in Spray also contains an import manager that is used 
already in some of the Spray templates.  I just did no get around to use it in 
all templates. Can we compare the use of ImportUtil and XtendProperties ?

Original comment by joswar...@gmail.com on 23 Sep 2011 at 11:58

[GoogleCodeExporter]

Original comment by karsten....@googlemail.com on 26 Sep 2011 at 10:33

• Changed state: Started

[GoogleCodeExporter]

I will investigate the use of XtendProperties. The import manager used there is 
quite simple. I have leveraged the one from EMF, which is far more advanced. I 
am not completely sure in which extend it does also more for us. But I'd prefer 
to reuse such a component before having an own one.

Original comment by karsten....@googlemail.com on 27 Sep 2011 at 9:27

[GoogleCodeExporter]

Sounds like a good idea, if the already existing one ash everything we need, 
let's reuse it.

Original comment by joswar...@gmail.com on 27 Sep 2011 at 9:35

[GoogleCodeExporter]

I have documented the pattern here:
http://code.google.com/a/eclipselabs.org/p/spray/wiki/DevGuide_Generator?ts=1317
117450&updated=DevGuide_Generator#Import_Organizing

If possible I want to get rid of calling 'importUtil.initImports', or just move 
it to FileGenerator.

Original comment by karsten....@googlemail.com on 27 Sep 2011 at 10:01

[GoogleCodeExporter]

Moved logic to FileGenerator and refactored template code. Using the 
"MARKER_IMPORT" marker comment.

Updated DevGuide: 
http://code.google.com/a/eclipselabs.org/p/spray/wiki/DevGuide_Generator

Original comment by karsten....@googlemail.com on 4 Oct 2011 at 5:20

• Changed state: Fixed