search

eMoflon / emoflon-ibex

Shared, eMoflon-specific component for incremental unidirectional and bidirectional graph transformations
GNU General Public License v3.0
13 stars 4 forks source link

Guidelines for using ibex in the production #394

Closed xmichael91 closed 5 years ago

xmichael91 commented 5 years ago

Hello. Can someone provide some guidelines about integration emoflon-ibex in real-word Eclipse-based application? So far I've followed handbooks and existing guidelines, made a workspace where I experiment with the engine and rules. Now I'm trying to integrate Emoflon TGG transformations engine into my existing application based on Eclipse RCP to be able to perform programmatical bidirectional transformations of my program models as a part of a project build process. It should be transparent to an end user and will be hidden behind some "Build" button. It should operate on two EMF business-models trg/src and use statically built TGG rules (.xmi, not source .tgg). I've encountered an issue with emoflon-ibex dependency hierarchy. As the base I have used example INITIAL_FWD_App, which does its job depending on these plugins which seems to be totally fine:

The problem is, org.emoflon.ibex.tgg.core.runtime depends on org.emoflon.ibex.tgg.editor, hence some .ide, .ui and even plantuml and jdt plugins... That means trying to use emoflon-ibex runtime brings almost all Emoflon development environment to my application. May someone make few notes about what are my next steps to solve this problem? May be I should try to fork repository and cut out editor and UI parts. Or isn't an integration like this even makes sense yet? Thanks!

anthonyanjorin commented 5 years ago

Hi @xmichael91,

as you have already guessed, the whole point in establishing "runtime" plugins is to minimise dependencies for the end user.

I don't understand why these plugins have editor and ui dependencies as you mentioned and this shouldn't be the case really :)

Let me take a look and get back to you as soon as possible.

Cheers and thanks, Tony

anthonyanjorin commented 5 years ago

Hi @xmichael91,

how exactly are you going about extracting all the dependencies you require to establish a run-alone solution?

If I use Eclipse to export an executable jar and provide INITIAL_FWD_App as a launch configuration, I get a fairly reasonable compilation of dependencies (that does not include plantuml or any *ui stuff). This is how I create stand-alone jars when I have to (e.g., for integration into other programs). (The jar is however still about 9MB large due to guava, emf, apache libs, and all the stuff for the interpreter.)

Would this work for you? Our runtime projects do depend on editor and ide plugins but, e.g., the plantuml or jdt dependencies are not exported and are thus not compiled into the generated jar.

(Our dependency structure is far from optimal but it won't be a trivial task to clean it up as everything is optimised for running inside Eclipse.)

Cheers, Tony

xmichael91 commented 5 years ago

Hi, @anthonyanjorin , thanks for your answers! I've got your idea. I've removed emoflon plugins from the Require-Bundle list of my plugin, and instead placed the minimal set of dependency libraries directly in the lib/ directory of my plugin and added all that jars to the classpath (Bundle-ClassPath). This way the application started fine. It included only the "runtime" dependencies, so this is an ok workaround for the problem, thanks again. cadxform Although with my relatively large source model and few TGG rules the application somehow indefinitely collecting matches, reporting millions of matches. I will open a new issue about this, if I will be able to build generic model to reproduce the problem.

anthonyanjorin commented 5 years ago

Hi @xmichael91,

depending on your meta-model and patterns (simple, small patterns tend to be particularly nasty), you might really be getting millions of matches. Especially due to symmetry or other surprising ways of matching your patterns.

Something I should say: IBeX is optimised for incremental applications, where you maintain a model and constantly make numerous small changes. It is not particularly well-suited for large-scale forward/backward transformations as it simply doesn't scale in such a setting. It is also mainly a tool for teaching, for which scalability wasn't a primary requirement.

Due to some recent industrial applications with huge models, I have started working on porting eMoflon to Neo4j. We aren't very far yet, but if you're interested we can grant you access.

Cheers, Tony