Community
Participate
Working Groups
You might find the title confusing, here is an explanation : I'm building an RCP headless application, thanks to PDE and Eclipse I can easily export my application as a standalone app containing all the jars I need. Part of this application is an Acceleo 3.1 *standalone* generator. It depends on really few things then. Problem is, as I'm calling it from a context where Eclipse is running it requires me to have the JDT and PDE and I ends up with NoClassDef. Caused by: org.osgi.framework.BundleException: Exception in org.eclipse.acceleo.common.AcceleoCommonPlugin.start() of bundle org.eclipse.acceleo.common. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:734) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:268) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107) ... 26 more Caused by: java.lang.NoClassDefFoundError: org/eclipse/jdt/core/JavaModelException at org.eclipse.acceleo.common.AcceleoCommonPlugin.start(AcceleoCommonPlugin.java:238) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702) ... 32 more I guess it's not going to the "standalone paths" but the plugin ones. Not sure why JDT is getting loaded during the AcceleoCommonPlugin.start(). may be org.eclipse.emf.common.EMFPlugin.IS_ECLIPSE_RUNNING usages within Acceleo should be changed in something I could hi-jack from the API...
I tried on a local copy of Acceleo and bypassing the ECLIPSE_IS_RUNNING did work if I also change the acceleo.common Manifest to avoid calling "start" if one of its class is loaded.
Hi, sorry to reanimate this old bug, but I'm exactly in the situation described here. We have developped an infrastructure to easily deploy minimal RCPs for standalone batch tools, allowing to keep the benefits of OSGI/Equinox infrastructure (extension points, EMF related registry initializations etc.). Our executable are generally something like 5MB and can work without data and user configuration areas (with @none related arguments). But if we want to embed acceleo generators, our RCP are immediatly growing to something like 120MB due to JDT core and workbench related dependencies. Those dependencies are stated as optional, but if we don't embed them in the RCP, we get exceptions like : classNotfoundException org.eclipse.jdt.core.JavaModelException cannot be found by acceleo.common_3.4.2.... FYI, EMF proposes a specific vmarg : -Dorg.eclipse.emf.ecore.plugin.EcorePlugin.doNotLoadResourcePlugin=true that allows run an OSGI based standalone application without using workspace related code. Do you think you could propose the same approach? Thanks in advance, Best regards, Seb
Hi, and thank you for bumping this bugzilla up with your comment. That's, indeed, the same problem. There are different "levels" of support we can get 1- making sure the generator does not depend on JDT/PDE: we could review all the code path and make sure that's effectivement the case *at runtime* (and avoid those NoClassDefFound) but it's always brittle over time. I would go with extracting this code into a specific plugin so that by construction we are sure Acceleo will not call this code. 2a- avoiding the workspace depenncy at runtime : we could "guard" the code just like EMF does with org.eclipse.emf.ecore.plugin.EcorePlugin.doNotLoadResourcePlugin=true , and refactor to make sure any code currently made ResourcesPlugin.getWorkspace().getRoot() is replaced with a proper API which takes in account the fact that the workspace might not even be there. 2b - removing the workspace dependency at build time : Now when I remove the o.e.core.resources dependencies and look at the code, only 4 classes in org.eclipse.acceleo.engine are actually depending on the Workspace API. We could probably go the "cleaner/more sustainable" route and extract those in a specific plugin then with the benefit that "out of the box" using P2 a generator would not bring those extra dependencies (not even the workspace !). We would still depend on core.runtime though but that's probably not a problem. "org.eclipse.acceleo.engine.generation.strategy.WorkspaceAwareStrategy" would have to move into this plugin (which would also remove the optional SWT dependency on o.e.acceleo.engine) Now, regarding API compatibility. At first sight the changes in o.e.acceleo.common can be made without impacting public API. Moving WorkspaceAwareStrategy is an API break. I would say all the other changes could be made without breaking the API. All in all, we could propose the same approach EMF does but we could also propose a better one by splitting this code (2b).
New Gerrit change created: https://git.eclipse.org/r/46536 WARNING: this patchset contains 3747 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
Gerrit change https://git.eclipse.org/r/46536 was merged to [master]. Commit: http://git.eclipse.org/c/acceleo/org.eclipse.acceleo.git/commit/?id=305ef44d94e09dd1abc6c20dbd70aff6117dafa6
New Gerrit change created: https://git.eclipse.org/r/53223
Gerrit change https://git.eclipse.org/r/53223 was merged to [master]. Commit: http://git.eclipse.org/c/acceleo/org.eclipse.acceleo.git/commit/?id=9ff5394803c0980a272213801dabafffc13e8d73
(In reply to Sebastien Revol from comment #2) > Hi, > sorry to reanimate this old bug, but I'm exactly in the situation described > here. > We have developped an infrastructure to easily deploy minimal RCPs for > standalone batch tools, allowing to keep the benefits of OSGI/Equinox > infrastructure (extension points, EMF related registry initializations etc.). > > [...] > > Seb Sebastien, all the changes are in and available through the following upadte-site: http://download.eclipse.org/acceleo/updates/nightly/streams/3.6.x Would that be possible to give it a try and confirm the problem is gone for your use case too ?
This has been fixed starting with Acceleo 3.6.2.
