Community
Participate
Working Groups
MWE2 execution currently doesn't work in OSGi. There are two problems: 1) MWE2 relies on indexing the class path in order to find any available MWE2 modules. There's a bit naive code in org.eclipse.xtext.mwe.RuntimeResourceSetInitializer which uses the system property "java.class.path". That can be easily overridden and exchanged, but I think we should provide a working story for OSGi. 2) The second problem is a bit more general and is not related to OSGi but to the global registry. If you run MWE2 from within a bundle and also have the MWE2 editor installed. You need to different configurations (i.e. Injectors). One is looking things up in the workspace, i.e. is backed up by the index and the other is using the classpath of the current bundle to find any referencable MWE2 modules. When resolving a cross reference the ResourceSet uses the global ResourceFactory.Registry to create a new one. However, there can only be one ResourceFactory for each extension. As a result things are mixed up. We should have a ResourceSet local shadowing ResourceFactory.Registry for all languages by default. And while we are on it, we might check whether there are other registries we want to handle equally (IResourceServiceProvider.Registry?) And yes, we might also consider to change MWE2 so that we can use classpath-URIs but I think the second problem mentioned above is a general thing we should improve on.
I ran into his issue while trying to run a mwe2 workflow inside an eclipse instance. For obvious reasons I don't want to create an mwe clone of my workflow. I did some research on issue 1) without success. Are there any ideas how to get a list of all mwe2 files reachable by a given bundle? Any pointers are appreciated. I'm not sure why the indexing is required, but couldn't be the indexing delayed as long as the mwe module2 name correspond to the workflow file name? The workflow could then be loaded as a resource on the bundles classpath. Only if a workflow could not be resolved by this strategy the indexing should be performed to find the module in on of the workflow files (workflow file name!=module name). At least in my case all file names correspond to the module name. Does this make sense?
postponed to M3
This is making my use case not workable either. It would be ok if it couldn't load the bundles as a resource from the plugin, but the real annoyance is that it seems to break behavior that works outside of OSGi. I can run my workflow using MWE2Runner under standalone using a file URI, but if I run the same code inside OSGi I get: java.lang.IllegalArgumentException: Couldn't find module with name 'workflow.generator'. at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:63) at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:52) For some reason it won't fall back to the file URI approach that worked -- which seems pretty broken. Not sure if I'm hitting case 1) or 2) here. Am I understanding right that there may be something funky happening with the editor/UI code that is causing this -- is that true only if it is an explicit dependency or might it even happen just because it happens to be present in the set of loaded bundles? If the issue is 1) then is there a workaround team can suggest? There are some really cool things that could be done with OSGi hosted server side stuff that this is blocking. the only thing I can think of is to launch an external java process but that seems pretty extreme.
OK, I could really use some hints about "That can be easily overridden and exchanged..." as it is not so easy for me. I thought I might just override getPathes() and include my workflow path manually, but that route is blocked because that expects to be injected somehow, so I get an NPE because there is no resourceSetProvider. And I can't fix that, because resourceSetProvider is private. So I thought to just write my own MWERunner, but naturally, that has a reference to Mwe2ExecutionEngine which itself expects to be injected with everything, and so on down the rabbit hole..
Miles, please outline what you are trying to do. Where are your mwe2 files located and where are the stuff it references (i.e. Java classes, other MWE2 files) located? Note that you'll only be able to run MWE2 workflows loading MWE2 files from our bundle (not from the workspace) if you never have org.eclipse.mwe2.language.ui installed. That is the mwe2 editor. This is because there can only be one ResourceFactory registered for the file extension .mwe2. The editor needs one which links to stuff from the workspace but if you want to run the MWE2 file within your bundle you need to link to stuff from your classpath. With easily overridden I meant: 1) RuntimeResourcesetInitializer 2) override org.eclipse.xtext.mwe.RuntimeResourceSetInitializer.getClassPathEntries() to return the right list of pathes (however you do this) 3) add a binding from RuntimeResourcesetInitializer to your new Subclass in Mwe2RuntimeModule But I think that won't be sufficient, as the second issue will be even more important.
Thanks for the very helpful response, Sven. (In reply to comment #5) > please outline what you are trying to do. > Where are your mwe2 files located and where are the stuff it references (i.e. > Java classes, other MWE2 files) located? The mwe2 and xpand templates / extensions could be either in local file system/URI or an OSGi installed bundle. Obviously, I'd prefer the latter, but the former could work ok as well..and actually that has some advantages as it would allow modifying the templates and workflow without having to deploy a new set of plugins. The target models are EMF and would need to be loadable from within a bundle session, e.g. referenced from a deployed RAP bundle using a File URI, and/or from a shared (I'm not going to worry about contention yet!) web URL/URI. (The file cannot be local for browser side security reasons.) Worst case, I suppose we could persist the model to the server side and load it from there as a file resource. Eventually, I'd like to be able to use any kind of EMF Resource, e.g. CDO, Binary, etc.. > Note that you'll only be able to run MWE2 workflows loading MWE2 files from our > bundle (not from the workspace) if you never have org.eclipse.mwe2.language.ui > installed. That is the mwe2 editor. OK, so let me put that in the opposite way to see if I got it. :) If I have org.eclipse.mwe2.language.ui as a loaded bundle then I cannot refer to a workflow contained in one of my bundles, but as long as I don't include that (I don't) then I should be able to use a workflow from my bundle? Is it possible that the inverse true, i.e. if I don't have org.eclipse.mwe2.language.ui installed then I can't load from file resource? In the non org.eclipse.mwe2.language.ui case then how would I refer to the workflow in the bundle? Not by platform:/resource I presume, but IIRC platform:/plugin doesn't work either. So should I refer to it as always in the past, i.e. with a project/plugin relative path for which it will be resolved against any bundle class path? I'm thinking that I could not get that to work, but I may be wrong about that. > This is because there can only be one ResourceFactory registered for the file > extension .mwe2. > The editor needs one which links to stuff from the workspace but if you want to > run the MWE2 file within your bundle you need to link to stuff from your > classpath. Yes, that makes sense now. So is the proposed solution then to create some kind of wrapper resource factory for mwe2 that allowed itself to be extended with arbitrary resource factor(ies)? > > With easily overridden I meant: > 1) RuntimeResourcesetInitializer > 2) override > org.eclipse.xtext.mwe.RuntimeResourceSetInitializer.getClassPathEntries() to > return the right list of pathes (however you do this) > 3) add a binding from RuntimeResourcesetInitializer to your new Subclass in > Mwe2RuntimeModule I was totally with you on steps 1 and 2 but 3 is the part where I meant that it wasn't so easy for me. :) I was sort of hoping to do this programmatically, i.e. the dumb old-fashioned way. I don't have access to any of these classes, so how would I add a binding to it? Would I subclass Mwe2RuntimeModule as well using bind[??], and somehow register that for mwe2, or do I do something like: Injector injector = new Mwe2StandaloneSetup().createInjectorAndDoEMFRegistration(); injector.getBindings().put(... //Some kind of key and binding in here but have no idea what they would be.. Mwe2Runner runner = injector.getInstance(Mwe2Runner.class); > But I think that won't be sufficient, as the second issue will be even more > important. I think perhaps I don't need to worry about issue 2 actually, as there wouldn't be a need for an MWE editor anywhere in the deployed application..
(In reply to comment #6) > Thanks for the very helpful response, Sven. > > (In reply to comment #5) > > please outline what you are trying to do. > > Where are your mwe2 files located and where are the stuff it references (i.e. > > Java classes, other MWE2 files) located? > > The mwe2 and xpand templates / extensions could be either in local file > system/URI or an OSGi installed bundle. Obviously, I'd prefer the latter, but > the former could work ok as well..and actually that has some advantages as it > would allow modifying the templates and workflow without having to deploy a new > set of plugins. > > The target models are EMF and would need to be loadable from within a bundle > session, e.g. referenced from a deployed RAP bundle using a File URI, and/or > from a shared (I'm not going to worry about contention yet!) web URL/URI. (The > file cannot be local for browser side security reasons.) Worst case, I suppose > we could persist the model to the server side and load it from there as a file > resource. Eventually, I'd like to be able to use any kind of EMF Resource, e.g. > CDO, Binary, etc.. EMF models and the like are loaded by the workflow components so the MWE2 engine doesn't really care. That is: It should just work. The interesting resources are the Java workflows and the workflow files. Those have to be on the pathes you specify in org.eclipse.xtext.mwe.RuntimeResourceSetInitializer.getClassPathEntries() > > Note that you'll only be able to run MWE2 workflows loading MWE2 files from our > > bundle (not from the workspace) if you never have org.eclipse.mwe2.language.ui > > installed. That is the mwe2 editor. > > OK, so let me put that in the opposite way to see if I got it. :) If I have > org.eclipse.mwe2.language.ui as a loaded bundle then I cannot refer to a > workflow contained in one of my bundles, but as long as I don't include that (I > don't) then I should be able to use a workflow from my bundle? Is it possible > that the inverse true, i.e. if I don't have org.eclipse.mwe2.language.ui > installed then I can't load from file resource? exactly. > > In the non org.eclipse.mwe2.language.ui case then how would I refer to the > workflow in the bundle? Not by platform:/resource I presume, but IIRC > platform:/plugin doesn't work either. So should I refer to it as always in the > past, i.e. with a project/plugin relative path for which it will be resolved > against any bundle class path? I'm thinking that I could not get that to work, > but I may be wrong about that. The URI isn't the problem. The implementation does the following (silly) thing: It first loads the MWE2 module by URI. then it takes the qualified name from it and loads the (hopefully) same module by name (i.e. from the specified classpath). As it uses the system classpath property by default the second step failed in your case. As soon as the classpath is properly set up it should work. > > > This is because there can only be one ResourceFactory registered for the file > > extension .mwe2. > > The editor needs one which links to stuff from the workspace but if you want to > > run the MWE2 file within your bundle you need to link to stuff from your > > classpath. > > Yes, that makes sense now. So is the proposed solution then to create some kind > of wrapper resource factory for mwe2 that allowed itself to be extended with > arbitrary resource factor(ies)? No, the idea is to not touch the ResourceFactory.Registry.eINSTANCE at all, but put the resourcefactory into the ResourceSet-local Registry. > > > > > With easily overridden I meant: > > 1) RuntimeResourcesetInitializer > > 2) override > > org.eclipse.xtext.mwe.RuntimeResourceSetInitializer.getClassPathEntries() to > > return the right list of pathes (however you do this) > > 3) add a binding from RuntimeResourcesetInitializer to your new Subclass in > > Mwe2RuntimeModule > > I was totally with you on steps 1 and 2 but 3 is the part where I meant that it > wasn't so easy for me. :) I was sort of hoping to do this programmatically, > i.e. the dumb old-fashioned way. I don't have access to any of these classes, > so how would I add a binding to it? Would I subclass Mwe2RuntimeModule as well > using bind[??], and somehow register that for mwe2, or do I do something like: > > Injector injector = new > Mwe2StandaloneSetup().createInjectorAndDoEMFRegistration(); > injector.getBindings().put(... //Some kind of key and binding in here but have > no idea what they would be.. > Mwe2Runner runner = injector.getInstance(Mwe2Runner.class); > I meant something like this: Injector injector = new Mwe2StandaloneSetup() { @Override public Injector createInjector() { return Guice.createInjector(new Mwe2RuntimeModule(){ public Class<? extends RuntimeResourceSetInitializer> bindRuntimeResourceSetInitializer() { return MySubTypeOfRuntimeResourceSetInitializer.class; } }); } }.createInjectorAndDoEMFRegistration(); I hope that helps, Sven
OK, thanks Sven.. I *think* I have it working though I haven't tried it in target platform yet. A little more detail on code: public class OSGiLauncher implements Runnable{ static class OSGiResourceSetInitializer extends RuntimeResourceSetInitializer { public List<String> getClassPathEntries() { List<String> classPathEntries = super.getClassPathEntries(); classPathEntries.add(0, "[My local absolute path to **jar**]"); return classPathEntries; } } public void run() { Injector injector = new Mwe2StandaloneSetup() { @Override public Injector createInjector() { return Guice.createInjector(new Mwe2RuntimeModule() { public Class<? extends RuntimeResourceSetInitializer> bindRuntimeResourceSetInitializer() { return OSGiResourceSetInitializer.class; } }); } }.createInjectorAndDoEMFRegistration(); Mwe2Runner runner = injector.getInstance(Mwe2Runner.class); Map<String, String> map = new HashMap<String, String>(); map.put("modelPath", Catalog.DEFAULT_LINEAGE_FILE); map.put("targetDir", Catalog.OUTPUT_DIR); URI createFileURI = URI.createFileURI("[My local absolute path to **workflow**"); runner.run(createFileURI, map); } } Now here's the part that I found weird. I could only get it to work if I include the exported jar file containing the workflow in the classpath, but then use the actual file system path for the workflow reference. In my testing case, these are in completely different places, though of course one could make things more maintainable by using the same location (and not jarring the plugin). I haven't experimented to see which file is actually used to run the workflow but obviously we can't be using both. It almost seems like the first resource step is a validation (the file exists) and the second is the actual invocation. In any case, it does seem to work, so I'm willing to remain confused on the rest of it for now. :)
(In reply to comment #8) > Now here's the part that I found weird. I could only get it to work if I > include the exported jar file containing the workflow in the classpath, but > then use the actual file system path for the workflow reference. In my testing > case, these are in completely different places, though of course one could make > things more maintainable by using the same location (and not jarring the > plugin). So the URI points to a different physical location, than the workflow file in the jar? As I mentioned earlier the code loads up the workflow file given the URI and takes its qualified name (i.e. the "module foo.bar.baz" part). Just to load the (hopefully same) module from the specified class path by name. You could invoke the runner by a qualified name in the first place, so you don't have to bother about URIs at all.
Just getting back to this. (In reply to comment #9) > (In reply to comment #8) > > Now here's the part that I found weird. I could only get it to work if I > > include the exported jar file containing the workflow in the classpath, but > > then use the actual file system path for the workflow reference. In my testing > > case, these are in completely different places, though of course one could make > > things more maintainable by using the same location (and not jarring the > > plugin). > > So the URI points to a different physical location, than the workflow file in > the jar? Yes, weird but true.. > As I mentioned earlier the code loads up the workflow file given the URI and > takes its qualified name > (i.e. the "module foo.bar.baz" part). Just to load the (hopefully same) module > from the specified class path by name. > You could invoke the runner by a qualified name in the first place, so you > don't have to bother about URIs at all. COuld you say more about this last bit? That "module " part threw me. It sounds like we want more than just the path from classpath.
(In reply to comment #10) > (In reply to comment #9) > > As I mentioned earlier the code loads up the workflow file given the URI and > > takes its qualified name > > (i.e. the "module foo.bar.baz" part). Just to load the (hopefully same) module > > from the specified class path by name. > > You could invoke the runner by a qualified name in the first place, so you > > don't have to bother about URIs at all. > > COuld you say more about this last bit? That "module " part threw me. It sounds > like we want more than just the path from classpath. I just wanted to say, that if you have an mwe2 module like """ module foo.bar.Baz ... """ contained somewhere in some *.mwe2 file on your classpath. You couldload it using the qualifiedName "foo.bar.Baz" instead of using an EMF UR using org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(String, Map<String, String>).
> contained somewhere in some *.mwe2 file on your classpath. You couldload it > using the qualifiedName > "foo.bar.Baz" instead of using an EMF UR using > org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(String, Map<String, > String>). Oh yep, that's what I was doing. It was the "module" part that was confusing me. Right now I'm experimenting with an approach where I install the plugin unpacked and then I can use it form a file URI, classpath or bundle as needed. Though now that I think about it, I'm not sure why I'm not just using the -plain based MWE generators that I've already developed..must be a good reason but I can't remember what it is now..
I'm trying my old MWE approach, since I had that all working before (and I'm having trouble dealing with MWE2 classpath issues) and I realized that I spent a lot of time figuring out class path issues for that. The AMP builder uses plugin provided workflows and xpand and xtend artifacts against resource provided models and it works perfectly. A couple of things to note are that I actually switch out the context class loader for the model generation itself -- I think I must have done that to prevent some of the issues you mention below -- and I force activation of the plugin containing those workflows by loading the activator. If you're curious, here are some of the relevant classes: http://git.eclipse.org/c/amp/org.eclipse.amp.git/tree/org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.ide/src/org/eclipse/amp/amf/gen/ide/AbstractMWEBuilder.java http://git.eclipse.org/c/amp/org.eclipse.amp.git/tree/org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.ide/src/org/eclipse/amp/amf/gen/ide/MetaABMBuilder.java You can generate directly using handlers as well.. http://git.eclipse.org/c/amp/org.eclipse.amp.git/tree/org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.ide/src/org/eclipse/amp/amf/gen/ide/GenerateInterfaceHandler.java (The code also manages EMF markers produced by checks and reports generation errors and successes gracefully to Status log.)
Created attachment 212301 [details] log file generation
Hi, I try to use mwe2 with version 2.0.1 and i what to execute a simple workFlow in bash mode (which defined in the content help of eclipse: Workflow { component = SayHello { message = "Hello World!" } } and i create the assiciated JAVA class of sayHello with the mwe2 launcher it works fine in fact i created a new class which implement the IApplication interface public class MWE2Application implements IApplication { private String mwe2Module = "pathtomodule.mwe2"; @SuppressWarnings("deprecation") public Object start(IApplicationContext context) throws Exception { // get input argument from the run of the eclipse application Map argMap= context.getArguments(); Object[] args =(Object[]) argMap.get("application.args"); parseArgs((String[])args); // create the workflowRunner Mwe2Runner mweRunner = new Mwe2Runner(); system.out.println("Starting Model Workflow Engine Standalone Application \n" ); Injector injector = new Mwe2StandaloneSetup() { @Override public Injector createInjector() { return Guice.createInjector(new Mwe2RuntimeModule(){ public Class<? extends RuntimeResourceSetInitializer> bindRuntimeResourceSetInitializer() { return MySubTypeOfRuntimeResourceSetInitializer.class; } }); } }.createInjectorAndDoEMFRegistration(); mweRunner = injector.getInstance(Mwe2Runner.class); mweRunner.run(mwe2Module, Collections.<String, String>emptyMap()); if (mwe2Module.contains("/")) { mweRunner.run(URI.createURI(mwe2Module), Collections.<String, String>emptyMap()); } else { mweRunner.run(mwe2Module, Collections.<String, String>emptyMap()); } return 0; } in fact i have these error (see log file)
Miles, what did you do at the end? Is it working using MWE2 or is it still required to copy or downgrade the workflows to MWE?
Hi Axel, Honestly, I can't remember. I think I may have just set up an OSGi (e.g. Virgo hosted) specific MWE2 generator with the code above -- I think I got that part working -- but I didn't go all the way into production with it. Sorry I can't give you more details, but they've been committed to deep archival memory, e.g. dev/null. :) cheers, Miles
Hi Miles, could you please leave some links/references of how you did the workaround with the mwe? Thanks!
any news on this?
Any intention to update this? Given that MWE2 is the presented as the default now, not having OSGI run capability for it seems a bit inconsistent.
I don't see how we can fix this. Note, that MWE2 generally works fine in OSGi and Equinox. The problem is that if you have the mwe2.ui plugin installed as well, the mwe configuration is set up in "development mode", i.e. it treats your workspace as the source for models and references, not the running bundles. So anybody who wants to use mwe2 in Eclipse just needs to deactivate (or not install at all) the mwe2.ui bundle. The simplest solution to support both, would be to generate Java from mwe2 files, which are then executed...
(In reply to Sven Efftinge from comment #21) > I don't see how we can fix this. > Note, that MWE2 generally works fine in OSGi and Equinox. The problem is > that if you have the mwe2.ui plugin installed as well, the mwe configuration > is set up in "development mode", i.e. it treats your workspace as the source > for models and references, not the running bundles. I guess I didn't realize that the issue was as simple as this. What about simply providing a configuration var that would allow us to override the development mode behaviour? Or even some kind of simple API? One issue can be that because other components depend on mwe2.ui, you often don't have really obvious control about excluding mwe2 ui from the build. But the biggest trouble is that we "expect" the behaviour to be the same under CI, deployment and running local self-hosting runtime. It's very hard to diagnose issues when the behaviour is different depending on deployment scenario. For some reason -- I'm not really sure why -- resources have always been a source of major confusion for EMF / x_ developers and this only makes things not just opaque but actually distorted. :)
(In reply to Miles Parker from comment #22) > (In reply to Sven Efftinge from comment #21) > > I don't see how we can fix this. > > Note, that MWE2 generally works fine in OSGi and Equinox. The problem is > > that if you have the mwe2.ui plugin installed as well, the mwe configuration > > is set up in "development mode", i.e. it treats your workspace as the source > > for models and references, not the running bundles. > > I guess I didn't realize that the issue was as simple as this. What about > simply providing a configuration var that would allow us to override the > development mode behaviour? Or even some kind of simple API? It's not that simple, because EMF relates on singletons. For instance there can only be one ResourceFactory associated to *.mwe2 files. > > One issue can be that because other components depend on mwe2.ui, you often > don't have really obvious control about excluding mwe2 ui from the build. Yes, I know. I don't consider this a solution to this problem. I just wanted to mention that. Maybe it helps one or the other. > But the biggest trouble is that we "expect" the behaviour to be the same > under CI, deployment and running local self-hosting runtime. Sure. > It's very hard > to diagnose issues when the behaviour is different depending on deployment > scenario. It is not different. The loading, linking and interpretation is based on Java classloader no matter where you execute it. It's really just that there's a conflict with singletons and two totally different configurations in the same VM for the same language. > For some reason -- I'm not really sure why -- resources have > always been a source of major confusion for EMF / x_ developers and this > only makes things not just opaque but actually distorted. :) I fear this complain is a bit too vague to be helpful. ;-) Actually, I wonder why anybody wants to execute MWE2 files within Eclipse. It's relatively easy to replace MWE with a Java file. With Xtend it gets even almost as readable as MWE2. It has the benefit that it is fast and debuggable and you don't need many dependencies at runtime. See http://20000frames.blogspot.de/2013/01/mwe2-workflows-using-xtend.html
(In reply to Sven Efftinge from comment #23) > Actually, I wonder why anybody wants to execute MWE2 files within Eclipse. > It's relatively easy to replace MWE with a Java file. With Xtend it gets > even almost as readable as MWE2. > It has the benefit that it is fast and debuggable and you don't need many > dependencies at runtime. > > See http://20000frames.blogspot.de/2013/01/mwe2-workflows-using-xtend.html Oh, that's *much* easier than the Java hackery I was doing before. I can live with that. :)
The Xtend based workflow is a very interesting approach indeed. Looks like MWE2 can be dropped somewhen in future.
I agree with the comments on Xtend. And in fact my first reflex was to look for the intermediate files that correspond to the mwe2 definitions. Finding none, I was flumoxed. So, I took it as necessary black magic. The reasons for having mwe2 work in this way that were given in the blog post are sound, too. But I believe that the installed base is being ignored here. This problem will rear its ugly head again and I agree with Miles that the behaviour certainly does not conform to expectation. Also, the need to manually run an injector from a class in an internal package, start bundles by hand or exclude CP entries does not seem like a graceful solution. So I would soundly disagree with Sven's assertion that "MWE2 generally works fine in OSGi and Equinox". If that were the case, the MWE2 launcher would not be implemented as a Java Launcher, but as an Eclipse launcher. The design is a bad match for OSGI. In fact, the previous MWE1 launcher seems to have been working, and from that point of view MWE2 is a definitive regression and its claim in the public documentation to be fully compatible is false and should be revised. In case Sven wonders "why anybody wants to execute MWE2 files within Eclipse" I would like to provide the following enterprise scenario: * Your company has a product line of code generators. * The generators have corresponding MDE workflows. * The workflows are modular and have reuse. * The workflows need to ship as part of RCP products to customers (and hence run in "Eclipse") Further: * There is a substantial installed base. * There is a need to edit the workflows consistently with editor support. Given the above motivation "rewrite it in Xtend" does not seem very feasible. So I would be grateful for any useful advice other than to tell management: "Sorry, but the Xtext suite has Bug 318721 and 'I don't see how we can fix this.'" or "Dump it and rewrite it, it is not that hard.". I am not dismissive, but I am quite surprised at this bug. It surely instills in me an increased need to exercise increased caution in tool selection.
(In reply to Jörn Guy Süß from comment #26) Could you please calm down a bit and explain exactly what you want to do. There are many different things mixed up in this bug and I'm really not sure what your issue is. Please answer these questions: 1) Does the MWE2 file you want to execute sit in the workspace or is it jared in one of the installed bundles? 2) If it's in the workspace, where are the referenced Java artifacts? Workspace or installed bindle? 3) What is the actual problem you face?
(In reply to Jörn Guy Süß from comment #26) > * Your company has a product line of code generators. > * The generators have corresponding MDE workflows. > * The workflows are modular and have reuse. > * The workflows need to ship as part of RCP products to customers (and hence > run in "Eclipse") So I assume this is *your* scenario? I think it should work fine as long as you just don't add mwe2.ui to the RCP product.
I am complete calm. Thank you. In response to your questions: WRT. scenario you are largely correct. The workflows are distributed over several bundles with their corresponding artifacts. They reference each other. A UI dispatches them for non-experts. In addition, I intend to deploy with a headless app as part of a maven tycho CI in Jenkins using a run application extension. WRT use case details: 1) Does the MWE2 file you want to execute sit in the workspace or is it jared in one of the installed bundles? (It is) They are jared in (one of the) installed bundles. 2) If it's in the workspace, where are the referenced Java artifacts? Workspace or installed bindle? It is not in the workspace. 3) What is the actual problem you face? * At the current time I am trying to execute MWE2Runner inside a plugin test. My aim is to provide resources bundled in the test plugin to the runner, and subsequently observe and compare results generated in java.temp to guard against regression in workflows and underlying components. (System test, smoke test) * Eventually I would use the same strategy to execute the workflows in CI or a UI based tool. ==== Non subject matter below ===== Finally, please do not take my comments personally. I meant them to be factual. As the thread shows: * Use of the runner/launcher within OSGI is neither documented nor simple, but plugin use is Eclipse's mainstay. * The documentation asserts a property (compatibility) that does not hold in practice in this instance. Do not get me wrong. I think that xText and related tools are great and injection is an elegant architecture choice. However, I personally value known limitations to be visible. So a simple "but this does not work for/in" in the documentation would have probably done it for me.
(In reply to Jörn Guy Süß from comment #29) > 3) What is the actual problem you face? > > * At the current time I am trying to execute MWE2Runner inside a plugin > test. My aim is to provide resources bundled in the test plugin to the > runner, and subsequently observe and compare results generated in java.temp > to guard against regression in workflows and underlying components. (System > test, smoke test) And that doesn't work? What's the actual problem? > * Use of the runner/launcher within OSGI is neither documented nor simple, > but plugin use is Eclipse's mainstay. Yes, running MWE within Eclipse has problems (see this bugzilla), but it seem that some people want to do that. So I try to help. > * The documentation asserts a property (compatibility) that does not hold in > practice in this instance. Could you point me to the part of the documentation you are referring to?
Surface phenomenon / underlying cause (AFAIK): The mwe2 files are not found. This seems to go back to the RunTimeResourceSetInitializer.getCPEntries not returning any resources, as it looks at the java.classpath. Would you like a testcase? Documentation reference: The sentence in the documentation I am referring to is http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.xtext.doc%2Fhelp%2FMWE2.html "The Modeling Workflow Engine 2 (MWE2) is a rewritten _backwards_ _compatible_ implementation of the Modeling Workflow Engine (MWE)." (emphasis added) Reason: In MWE1 the OSGI execution was possible, but clunky. (I have an example to show this.) I take the term "backwards compatibility" to mean replaceability for most common, if not for all cases. Given how common plugin use is in Eclipse and the fact the runners are provided as public plugin API, I would have expected that MWE2 would provide the same functionality. I am grateful for your effort invested in this issue. I understand that it may seem marginal for interactive and casual users of xText.
I think this an important problem to address. We have an extensive set of workflows that we've been using for inhouse development. These workflows combine to read in several models, produce several models, and produce code and documentation artifacts. We combine pure-Java, QVTO, and Acceleo transforms. This all works great when launched using an MWE2 launch configuration. We now have a requirement to be able to package this up for other organizations to use. The metamodels, transforms, and workflows are all packaged up as plug-ins and combined into our Eclipse-based product. The product provides a model editor for one of the model types and control functions that allow the workflow to be executed. However, we cannot get the workflow to execute because of the problems outlined in this bug. It is true that the workflow ultimately invokes Java code, so it looks like we are faced with rewriting the MWE2 workflows in Java (and therefore abandoning the use of MWE2, since we won't want to have to maintain two different expressions of the same workflow). This is a shame, because the MWE2 workflows neatly express the set of transforms.
see also bug 491761.
(In reply to Moritz Eysholdt from comment #33) > see also bug 491761. This is not about classpath dependencies but about running in equinox. So bug 491761 is not related.
Is there any progress regarding this bug.. From bugzilla, I see that this topic is discussed over several years but I couldn't find any definite solution :-( In my case, I am building a headless RCP application which is invoking mwe2 workflow (not bundled inside the application). As execution of MWE2 workflow from a eclipse instance is not working, I am blocked. I described my problem at this forum : https://www.eclipse.org/forums/index.php/m/1799561/#msg_1799561 From the below comments I found a hint: "not to have mwe2.ui in the runtime", but unfortunately this doesn't seem to valid for mwe2 version I am using as I couldn't see mwe2.ui in 2.9.1 version. Only below plugins are available org.eclipse.emf.mwe2.language_2.9.1.201705291011 org.eclipse.emf.mwe2.language.ui_2.9.1.201705291011 org.eclipse.emf.mwe2.launch_2.9.1.201705291011 org.eclipse.emf.mwe2.launch.ui_2.9.1.201705291011 org.eclipse.emf.mwe2.lib_2.9.1.201705291011 org.eclipse.emf.mwe2.runtime_2.9.1.201705291011 Documentation : I have created step by step explanation of the plugins I have created + how I have used MWE2Launcher (in both the modes) : https://github.com/zam1kor/mwe2_execution/blob/4a31bbb/Issue_description.docx?raw=true info: both sources and docu are available in github repo : https://github.com/zam1kor/mwe2_execution.git
no. there is nobody working on this.
i assume the problem is how classes are loaded e.g. in org.eclipse.xtext.common.types.access.binary.BinaryClass.forName(String, ClassLoader)
