Community
Participate
Working Groups
Build Identifier: Please provide a feature which contains no UI contributions and can be used for performing headless generations using the new ant template. Basically only the xpand plugins (without editors) and codegen plugins (without edit) should be contained. The ant-based generation works so far (only had to override the xpand template to adjust some stuff) - even with aspect templates. But the UI contributions cause exceptions preventing the actual product build. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=315183 for the background story. Reproducible: Always
Tried to do an own wrapping feature, but org.eclipse.gmf.common seems to have UI dependencies already. What can I do now?
[GMF Restructure] Bug 319140 : product GMF and component Generation was the original product and component for this bug
Vote +1
Please list the set of bundles you need for a "GMF headless feature" and we'll add one. However, I think having a feature for headless stuff does not make a lot of sense if you install your deps with p2. Just ask for what you want, and you'll get it + its only necessary deps.
Hi Mickael, thanks for your answer. I think the only two required plugin bundles are 1. everything from the org.eclipse.gmf.xpand feature except org.eclipse.gmf.xpand.editor 2. org.eclipse.gmf.codegen and maybe org.eclipse.gmf.validate The xpand plugin is required for running the xpand build template (which has been generated by an ant task before). The codegen plugin contains this xpand build template as well as all other templates used for the actual editor generation. Ideally the headless feature is as much self-containing as possible. For example the only external dependencies should point to some (non-ui) eclipse and emf stuff. If for example org.eclipse.gmf.codegen requires org.eclipse.gmf.common then this one should be included, too. This way step by step stuff can be incorporated revealing ui dependencies which must be separated then (e.g. org.eclipse.gmf.common requires org.eclipse.draw2d).
I think that if you take a fresh Equinox, and then you use to perfom a p2 installation of installation unit "org.eclipse.gmf.codegen", you'll get exactly all the jars you need. See http://wiki.eclipse.org/Equinox_p2_director_application/Examples/Install_into_dropins I am not very sure about your use-case: If you use anything else than Tycho, you need to have an instance of Eclipse to perform build. Then why don't you simply install GMF in it, and use the antRunner from this Eclipse?
I am doing the builds with buckminster [1] which uses something like headless installations where no UI contributions are allowed. The problem does not occur during installation (actually buckminster just delegates this to the p2 director), but when it comes to using the installed system later on. I do not know the exact background details, but somehow it relates to that the workbench tries to instantiate a user interface as soon as ui components have been contributed. Please read [2] for more reference information about the use case, especially the answers of Thomas Hallgren. Also worth to read may be [3,4] which cover similar issues but not related to gmf. [1] http://www.eclipse.org/buckminster/ [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=315183 [3] http://manuelselva.wordpress.com/2011/07/08/build-command-line-tools-on-top-of-eclipse/ [4] http://www.eclipse.org/forums/index.php/t/224795/
Ok, Then I am more pessimistic. This issue means that: * either one of the gmf plugins is an UI plugin, that requires UI to start. * either the generation code runs some UI code that requires a Display to be available. Directly or not (it can be one of the dependency that calls a Display). Maybe if you provide a stack trace of which bundle cannot start (in case 1) or of which line raise an exception (case 2), we'll find a way to remove this dependency on the UI.
