generic launcher

[kbojarczuk]

Hello,

I'm developing a Henshin Concurrent Engine for gemoc with @szschaler and I've noticed that I had to copy a lot of code into my launcher. It seems that there's no generic launcher so I was wondering if it would be possible add one in the next versions to reduce the code redundancy.

Your launcher

Our launcher

Thank you, Kinga

[dvojtise]

Hi, You're right we've also noticed that the current launchers architecture does not help code reuse. (we also have the same problem between the java engine and the ale engine) This is actually due to the fact that eclipse schema (used by plugin.xml) does not support "inheritance or extension" mechanism. So creating multiple launchers implies to duplicate code and schemas.

so actually this issue is more for https://github.com/eclipse/gemoc-studio-modeldebugging/ than for https://github.com/eclipse/gemoc-studio-execution-moccml

However, you're right we're also thinking about creating a generic launcher with our own extension points so a new engine would not need to create its own launcher but simply contribute extensions to the generic one. In the same process, these extension points should help to have a generic command line interface (contribution to https://github.com/eclipse/gemoc-studio/tree/master/gemoc_studio/plugins/org.eclipse.gemoc.gemoc_studio.headless + https://github.com/eclipse/gemoc-studio/issues/135) Our basic idea right now would be:

• have the possibility to add extension point declaring UI code to be added to the generic launcher tabs
• .dsl file would declare both a language but also the engine(s) (see https://github.com/eclipse/gemoc-studio/issues/91 ) that are expected to run models of this langauge, so when the user selects the language, this would activate the corresponding engine and associated UI. (both in the graphical interface or in the command line one)

thanks for having linked your project, we'll definitively have a look to support it when doing this action Didier

[szschaler]

Thanks, Didier. From our perspective, it would already be cool to just be able to reuse the launcher classes when building our own launcher. Currently, they're not exported from the plugin, though.

So, while I agree that the wider plan sounds very relevant and that we should like to get integrated into this, there seems to be a first short-term win here in simply exporting those classes from the plugin.

As for the wider plan: our language definition is basically a metamodel, a Sirius concrete syntax (for the moment, we would love to support other concrete syntaxes, but will go with what GEMOC supports for the time being) and an operational semantics in Henshin. Would this fit easily into the planned DSL specification language? If not, what is the best way for us to engage to help shape the DSL specification language accordingly?

Thanks, Steffen

[dvojtise]

If a simple "export package" is required in a plugin, please go ahead and create a pull request. We'll be happy to integrate contributions :wink: (also do not forget to commit using the sign-of-by and sign the Eclipse committer agreement)

about the wider plan, yes I think it would fit (anyway it must fit, otherwise there is a flaw in the design :wink:) as the current .dsl file is just a set of key/values this is mainly making sure that the keys we use are unique and, if possible, self explanatory. A given engin may use its own additional key/value. About the launcher part, I simply expect to have one key declaring "engine names/id" known to be able to run the language, then specific engines would contribute plugins extensions with this name/id