Skip to main content



      Home
Home » Modeling » TMF (Xtext) » GeneratorRegistry unleashed :-)
GeneratorRegistry unleashed :-) [message #1064239] Tue, 18 June 2013 07:16 Go to next message
Eclipse UserFriend
Hello guys,

I'm currently working on DSL project which should support multi generators.
In addition to that, these generators must be seperate plugins, to support a modular structure. With that structure you are able to deploy "features" per customer without changing your code.

So I found an easy solution for me and will share it with you:

1. Create a new Project and add a class named "GeneratorRegistry":

package de.ageiss.xtext.sam.generator.util

import java.util.List
import org.eclipse.xtext.generator.IGenerator
import java.util.Vector

class GeneratorRegistry {
	static List<IGenerator> generators = new Vector()
	
	def static List<IGenerator> getGenerators() {
		return generators
	}
	
	def static void registerGenerator(IGenerator generator) {
		if (generator != null) {
			generators.add(generator)
			println("[+] generator '" + generator + "' added to registry.")
		}
	}

}


2. Modify your current Generator as follow:

	override void doGenerate(Resource resource, IFileSystemAccess fsa) {
		println("[+] generator '" + this + "' starting...")
		generate(resource.contents.head as Model, fsa)
		for (generator : GeneratorRegistry::generators) {
			generator.doGenerate(resource, fsa)
		}
		println("[+] generator '" + this + "' done.")
	}


Now your generator (primary) is able to call the generate method for all the registred generators.

3. Create a new Plugin-Project for your new seperate generator with an Activator class as follows:

	public void start(BundleContext context) throws Exception {
		
		System.out.println("[+] activator '" + this + "' starting...");
		GeneratorRegistry.registerGenerator(new YourNewGenerator());
		
		super.start(context);
		plugin = this;
		
		System.out.println("[+] activator '" + this + "' done.");
	}


The generator is now able to register himself at startup into the GeneratorRegistry.

4. Create a new class named "Startup" which implements the "IStartup" interface and add create a plugin.xml as follows:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>

<plugin>
   
   <extension point="org.eclipse.ui.startup">
		<startup class="your.package.generator.Startup" />
	</extension>

</plugin>

[Updated on: Tue, 18 June 2013 11:00] by Moderator

Re: GeneratorRegistry unleashed :-) [message #1064295 is a reply to message #1064239] Tue, 18 June 2013 10:54 Go to previous messageGo to next message
Eclipse UserFriend
Note that you may also have a look at this project. Here the compiler preference page was customised so that registered generators can be turned on/off (per project).

(Warning: proof of concept code)

Alex
Re: GeneratorRegistry unleashed :-) [message #1064300 is a reply to message #1064295] Tue, 18 June 2013 11:03 Go to previous messageGo to next message
Eclipse UserFriend
Hi Alex,

thats another approach and a nice solution, too.

Thx

Andy
Re: GeneratorRegistry unleashed :-) [message #1064421 is a reply to message #1064239] Wed, 19 June 2013 04:06 Go to previous messageGo to next message
Eclipse UserFriend
Hi Andy,

Two things:

You could create a Dispatcher generator, which gets injected other generators. Then there is no need for more magic:

class MyGenerator implements IGenerator {
  @Inject Generator1 gen1
  @Inject Generator2 gen2

  override void doGenerate(Resource resource, IFileSystemAccess fsa) {
    gen1.doGenerate(resource,fsa)
    gen2.doGenerate(resource,fsa)
  }
}


You approach of course works, but I see these flaws:
- It requires a plugin with early startup. If this is forgotten to configure the approach will fail. Usually early startup should be avoided whenever possible.
- The static approach is a memory leak. The list never gets free. Not a big deal here, since the generators should be usually stateless. However, it would be better to hold a static instance which is created on start() and set to null on stop().

Best wishes,
~Karsten
Re: GeneratorRegistry unleashed :-) [message #1064540 is a reply to message #1064421] Wed, 19 June 2013 14:57 Go to previous messageGo to next message
Eclipse UserFriend
Hi Karsten,

my goal is to add more generators without changing my main generator.
Your approach requires to insert each generator via "@Inject" and call the doGenerate methode explicitly.

Think about shipping your own RCP product with your main generator and
someone could add new generators to your base environment on the fly by using the static class GeneratorRegistry.

Your right about the memory leak. I will change my design. Thanks for that point.

Andy
Re: GeneratorRegistry unleashed :-) [message #1064546 is a reply to message #1064239] Wed, 19 June 2013 16:08 Go to previous messageGo to next message
Eclipse UserFriend
Hello - just FYI: we built something similar to this (in-house / closed source) as well.. Ours is more along the lines of the GeneratorRegistry (with a dedicated extension point instead of startup based) than the Dispatcher generator with @Inject above. May be a future Xtext version could have support for "pluggable" Generators out of the box? Any interest in a (low-prio!) bugzilla about this?
Re: GeneratorRegistry unleashed :-) [message #1064565 is a reply to message #1064546] Wed, 19 June 2013 18:45 Go to previous messageGo to next message
Eclipse UserFriend
Hi Michael,

I'm very glad to see that someone build something similar to me (I must not be totally wrong).

A "pluggable" generator support in a future xtext version would be nice!
Re: GeneratorRegistry unleashed :-) [message #1064891 is a reply to message #1064565] Fri, 21 June 2013 10:19 Go to previous message
Eclipse UserFriend
https://bugs.eclipse.org/bugs/show_bug.cgi?id=411374
Previous Topic:Expression Grammar [fatal] Error
Next Topic:EFactory (reborn)
Goto Forum:
  


Current Time: Tue Jul 22 12:45:21 EDT 2025

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

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

Back to the top