[Sculptor 3] Template overriding and development of overridden templates

[Torsten Juergeleit]

The current implementation of the template overriding features does interfere with the development of overridden generator templates:

1. The Xtend editors outline view is littered with generated methods. For each public template method a generated "next_" method is show.
   
2. While typing in the Xtext editor the signature of a new public method the template overriding active annotation kicks in and generates the corresponding "next_" method.
3. Trying to navigate within the Xtend editor (via F3 on a method reference) to a overridden method gets you to the line with class definition instead.

Removing the "@ChainOverridable" class annotation makes this stuff go away.

It seems that generating the template overriding code into the overridden class comes with its cost.

Please check with the Xtend guys what they suggest to keep active annotations from interfering with the Xtext editor.

/Torsten

[Torsten Juergeleit]

Despite of using the latest version of Xtend 2.4.3 (which claims improvements on performance) I got the impression that our approach of "Putting @ChainOverridable on all templates" brings Eclipse (at least on my machine -> 2.3 GHz I7 with 16GB memory) down to a crawl. Sometimes after changing a single character in an annotated template I've to wait a few seconds to get a response from Eclipse. And yesterday I managed to bring down the whole Eclipse JVM v1.7.0_25 with an PermGen OOM (eclipse.ini setting of 2g heap and MaxPermSize=512m  =8-O ).

Additionally I've to add the following points to the list:

4. Searching for references of a method in an annotated method (shift+ctrl+g) is pretty useless. It only finds the dispatch method :-( Doing a search on the found dispatch method finds the "_chained_" methods of the referencing templates.

5. Using the Eclipse debugger to single-step through an annotated template is impossible due to the missing trace information for the code generated by the annotation.

So working with annotated templates is for me right now a major PITA :-(

/Torsten

[Pavel Tavoda]

References are problem, you have to find with search or I'm using Outline (CTRL+O).

However stepping through xtend templates in debug mode is OK. I have no problem with it.

When I'm thinking about your problem maybe we can develop small project 'sculptor-active-annotation-dummy' which we will use in Eclipse dependency which will do 'nothing' for @ChainOverridable annotation. However I don't know how well it will integrate with maven ... profiles?

/Pavel

[Torsten Juergeleit]

When I'm thinking about your problem maybe we can develop small project 'sculptor-active-annotation-

dummy' which we will use in Eclipse dependency which will do 'nothing' for @ChainOverridable annotation. However I don't know how well it will integrate with maven ... profiles?

That's a good idea. We could ship this as an Eclipse plugin which is bundled with the Sculptor Eclipse editor plugin.

But I've no clue yet on how to bring this dummy implementation of the  @ChainOverridable annotation into the classpath of Xtends compiler in front of the "real" annotation implementation added by the m2e Eclipse plugin.

/Torsten

[Torsten Juergeleit]

But I've no clue yet on how to bring this dummy implementation of the  @ChainOverridable annotation into the classpath of Xtends compiler in front of the "real" annotation implementation added by the m2e Eclipse plugin.

I think we've to come up with a m2e extension (implementation of "org.eclipse.m2e.jdt.AbstractJavaProjectConfigurator") as part of the Sculptor Eclipse feature which allows to manipulates an Eclipse projects classpath container. With this approach we could remove the Sculptor annotation JAR from the projects classpath and replace it with an JAR containing the dummy implementation.

I'm not sure if we should go the "whole way" by implementing a Sculptor project nature to indicate that this Eclipse project is manipulated. Using our own project nature gives us a chance to maintain state within the Eclipse project, e.g. for enabling/disabling the dummy implementation. Additionally we could attach our own graphical annotation (next to the Xtend natures ones) to the Eclipse projects node in the tree viewer :-)

/Torsten

[Pavel Tavoda]

I'm thinking/dreaming about graphical annotation long time. Our analytic guys can already write models directly in textual form but graphical annotation will be huge improvement.

However I don't want to do it before first 3.0 release.

Again I apply my 'KISS' principle. Can't we do it with 'profiles'? Include dummy in 'eclipse' profile (and normal in default active profile) and than in Project properties -> Maven you have possibility to set 'eclipse' as active profile.

Pavel

[Torsten Juergeleit]

I'm thinking/dreaming about graphical annotation long time. Our analytic guys can already write models directly in textual form but graphical annotation will be huge improvement.

No GUI editor here  =8-O
I was talking about a simple overlay annotation to a projects symbol in the resource viewer :-)

Again I apply my 'KISS' principle. Can't we do it with 'profiles'? Include dummy in 'eclipse' profile (and normal in default active profile) and than in Project properties -> Maven you have possibility to set 'eclipse' as active profile.

Yes, within m2e a Maven profile can be activated or deactivates ("!" prefix) via "Project > Properties > Maven > Active Maven profiles" on a per-project base.

The profile idea is good. But instead manipulating plugin dependencies I would use it for setting sculptor-related system properties (e.g. "sculptor-template-override"). How about tweaking ChainOverridableProcessor.validate() to check for a system property to skip processing an annotated class?
Maybe we can come up with a kind of a (comma-separated) pattern-based filter, e.g. default "sculptor-template-override=*" or filtered "sculptor-template-override=org.sculptor*,com.acme.*" or disabling template override via "sculptor-template-override=".

This way it's not neccessary to provide a new Maven dependency with a dummy implementation. And we don't have to refactor the Sculptor annotation support into it's own Maven dependency being excluded and replaced by the dummy Maven dependency.

/Torsten

[Pavel Tavoda]

On Monday, September 23, 2013 3:14:06 PM UTC+2, Torsten Juergeleit wrote:

I'm thinking/dreaming about graphical annotation long time. Our analytic guys can already write models directly in textual form but graphical annotation will be huge improvement.

No GUI editor here  =8-O
I was talking about a simple overlay annotation to a projects symbol in the resource viewer :-)

You read what you want to read. My bad.

 

Again I apply my 'KISS' principle. Can't we do it with 'profiles'? Include dummy in 'eclipse' profile (and normal in default active profile) and than in Project properties -> Maven you have possibility to set 'eclipse' as active profile.

Yes, within m2e a Maven profile can be activated or deactivates ("!" prefix) via "Project > Properties > Maven > Active Maven profiles" on a per-project base.

The profile idea is good. But instead manipulating plugin dependencies I would use it for setting sculptor-related system properties (e.g. "sculptor-template-override"). How about tweaking ChainOverridableProcessor.validate() to check for a system property to skip processing an annotated class?
Maybe we can come up with a kind of a (comma-separated) pattern-based filter, e.g. default "sculptor-template-override=*" or filtered "sculptor-template-override=org.sculptor*,com.acme.*" or disabling template override via "sculptor-template-override=".

This way it's not neccessary to provide a new Maven dependency with a dummy implementation. And we don't have to refactor the Sculptor annotation support into it's own Maven dependency being excluded and replaced by the dummy Maven dependency.

OK, looks good. For now I will stick with boolean enable/disable. Just one question. Do we have to define this variable at eclipse startup? Or is here some place in eclipse properties that Xtend compiler can pick it up.

[Torsten Juergeleit]

OK, looks good. For now I will stick with boolean enable/disable. Just one question. Do we have to define this variable at eclipse startup? Or is here some place in eclipse properties that Xtend compiler can pick it up.

Good point. This is a dead end with regards to Eclipse: Within Eclipse it's not possible to set system properties on-the-fly. This is only possible for launch configurations. And system properties have a global scope and not a project-only scope.

So we have to come up with a hybrid solution (half Maven / half Eclipse which knows about both worlds), e.g. by implementing a m2e extension. In this case the Sculptor Maven plugin (mainly the annotation processor) has to reach out to the Eclipse world and ask for eclipse-project-related properties somehow.

Maybe we should ask the Xtend guys regarding configuration of the Xtend compiler to keep certain active annotations from being executed.

/Torsten

[Ron Smith]

If we can modify the contents of the template method body in an Active Annotation, then we can hide these additional methods, and rewrite the template method to call the private methods instead of the regular method calls.

I don't think it's currently supported, but I posted a question to the xtend group to see if it was planned for in the future.

I'm also going to try another approach - to generate an inner class and have the additional methods generated there, hidden from anything using the regular (outer) class.

Ron

[Pavel Tavoda]

Question is if it will speed up compilation. I guess we have to, for development phase turn it off. Any change in generated output doesn't help with speed.

Or maybe we can wait for new Xtend release, they are promising to speed up.

[Pavel Tavoda]

Eclipse maven plugin is able to replace properties. I don't know if they are visible out of pom.xml. Maybe we can use them together with profiles.

If this will not work than I would like to use solution with profiles and changing dependencies. Advantage is you can switch profiles without necessity to restart eclipse. You can develop something with 'dummy' and than switch back to normal processing. I don't see any disadvantage with this solution.

[Torsten Juergeleit]

The Maven stuff (profiles with properties or different dependencies) is not available in the Eclipse world.

Within Eclipse the Xtend compiler runs as an Eclipse incremental build for every project in the Eclipse workspace which have the Xtext project nature and Xtext builder configured in their ".project" Eclipse config file.

Right now I can think of the following approaches available in both worlds:

1. System properties: In Maven these are set via Maven properties. But system properties have a global scope. So in Eclipse these properties are not usable on a per-project base.
   
2. Classpath resources: Loading a properties file from a classpath resource is available in both worlds. But parsing the contents of a file for every invocation of a state-less annotation processor seems pretty inefficient (performance). In both worlds we have to find a way to optionally put this file on the classpath.
   
3. Switching annotation processor implementation in classpath: For simply enabling or disabling the annotation processor we could manipulate the projects compile-time classpath (class shadowing). Within Eclipse we could come up with a project nature which adds a classpath container (containing a dummy implementation of the active annotation) to the very beginning of the projects classpath.

/Torsten

[Pavel Tavoda]

I developed small project with empty annotation and put it at beginning of classpath.

I did small test changing name of method 'fileOutput' in Helper.xtend to fileOutputXXX and save. With dummy annotation it take 32s with normal annotations it take 65s.

With dummy annotation, cartridges has errors because of missing next() method. It's still question if introducing 'next()' method with dummy processing will slow down compilation.
Attached is annotation-dummy project (pure eclipse project) if you want to test on your machine.

/Pavel

[Ivica Loncar]

On Tuesday, September 24, 2013 11:07:39 PM UTC+2, Torsten Juergeleit wrote:

The Maven stuff (profiles with properties or different dependencies) is not available in the Eclipse world.

JBoss tools allows you to select different maven profiles within eclipse. Would that help?

[Torsten Juergeleit]

JBoss tools allows you to select different maven profiles within eclipse. Would that help?

Nope. In Eclipse land no Maven stuff (profiles, plugins, ...) are used for compiling Xtend code. Instead an Eclipse project nature (here "Xext nature") together with an corresponding incremental builder (here "Xtext builder") with its Xtend compiler are used instead.

So Eclipse are Maven separate beasts with its own approaches and concepts. The Eclipse m2e plugin tries to bridge both worlds. But m2e is of no help in this case.

/Torsten