Eclipse Community Forums: Buckminster » Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects

Help

Home

Home » Archived » Buckminster » Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects

Show: Today's Messages :: Show Polls :: Message Navigator

Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects [message #546514]

Tue, 13 July 2010 09:02

Eclipse User

Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl

Hello all,

We use a lot of Eclipse Modeling Project technology (see subject of this
post). I'm trying to create an update site using Buckminster, with
Eclipse Helios, in headless mode.

I did:
- Install Buckminster headless using p2 director.
- Install core/pde/subversive headless features into Buckminster.
- Made an rmap and cquery to get my projects from SVN into the
workspace.
- Extended the EMF projects with a .spex and Ant build file to
generate sources from the genmodel.
- Created an update site from some feature that contains one of
the EMF projects.

I had some problems, like the Ecore2Java ant task not being found, so I
installed org.eclipse.emf into Buckminster, and that solved the problem.
I successfully created the p2 update site in headless mode. However, I
installed all (or at least a large part) of EMF...

So EMF is not a problem anymore, but the other types of projects I can't
figure out. For instance, I need to run a .mwe2 file to generate a
parser from my .xtext file. To this end I created a launch configuration
that runs the MWE2 file. It works from within my normal (non-headless)
Eclipse UI. However, it didn't in headless Buckminster. It couln't find
'org.eclipse.emf.mwe2.launch.Mwe2LaunchConfigurationType'. So, I
installed all featuers with 'mwe' and 'xtext' in the name into
Buckminster as well. Now I get new errors:

ERROR: Error logged from Debug Core:
org.eclipse.core.runtime.CoreException: Plug-in org.eclipse.debug.ui was 
unable to load class org.eclipse.debug.internal.ui.sourcelookup.Prompter.
         at 
org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.throwException(RegistryStrategyOSGI.java:194)
         at
(...)
Caused by: 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException: 
An error occurred while automatically activating bundle 
org.eclipse.debug.ui (113).
         at 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:121)
         at
(...)
Caused by: org.osgi.framework.BundleException: The activator 
org.eclipse.debug.internal.ui.DebugUIPlugin for bundle 
org.eclipse.debug.ui is invalid
         at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:156)
(...)
Caused by: java.lang.NoClassDefFoundError: 
org/eclipse/ui/plugin/AbstractUIPlugin
         at java.lang.ClassLoader.defineClass1(Native Method)
         at java.lang.ClassLoader.defineClass(Unknown Source)
(...)
Caused by: 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException: 
An error occurred while automatically activating bundle 
org.eclipse.ui.workbench (156).
(...)
Caused by: org.osgi.framework.BundleException: The activator 
org.eclipse.ui.internal.WorkbenchPlugin for bundle 
org.eclipse.ui.workbench is invalid
         at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:156)
(...)
Caused by: java.lang.NoClassDefFoundError: org/eclipse/swt/SWTError
         at java.lang.Class.getDeclaredConstructors0(Native Method)
         at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
         at java.lang.Class.getConstructor0(Unknown Source)
         at java.lang.Class.newInstance0(Unknown Source)
         at java.lang.Class.newInstance(Unknown Source)
         at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:151)
         ... 81 more
Caused by: java.lang.ClassNotFoundException: org.eclipse.swt.SWTError
         at 
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
(...)
Doing full workspace refresh
Waiting for jobs to end
java.lang.NoClassDefFoundError: org/eclipse/debug/ui/RefreshTab
         at 
org.eclipse.emf.mwe2.launch.shortcut.Mwe2LaunchDelegate.launch(Mwe2LaunchDelegate.java:25)
         at 
org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:853)
         at 
org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:702)
         at 
org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:695)
         at 
org.eclipse.buckminster.core.commands.Launch.internalRun(Launch.java:192)
         at 
org.eclipse.buckminster.core.commands.WorkspaceCommand.run(WorkspaceCommand.java:91)
         at 
org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(AbstractCommand.java:194)
         at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:317)
         at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:136)
         at 
org.eclipse.buckminster.cmdline.Headless.start(Headless.java:156)
         at 
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
(...)
Caused by: 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException: 
An error occurred while automatically activating bundle 
org.eclipse.debug.ui (113).
         at 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:121)
         at 
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453)
(...)
Caused by: org.osgi.framework.BundleException: The activator 
org.eclipse.debug.internal.ui.DebugUIPlugin for bundle 
org.eclipse.debug.ui is invalid
         at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:156)
(...)
Caused by: java.lang.NoClassDefFoundError: 
org/eclipse/ui/plugin/AbstractUIPlugin
         at java.lang.ClassLoader.defineClass1(Native Method)
         at java.lang.ClassLoader.defineClass(Unknown Source)
(...)
Caused by: 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException: 
An error occurred while automatically activating bundle 
org.eclipse.ui.workbench (156).
         at 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:121)
(...)
Caused by: org.osgi.framework.BundleException: The activator 
org.eclipse.ui.internal.WorkbenchPlugin for bundle 
org.eclipse.ui.workbench is invalid
         at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:156)
(...)
Caused by: java.lang.NoClassDefFoundError: org/eclipse/swt/SWTError
         at java.lang.Class.getDeclaredConstructors0(Native Method)
         at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
         at java.lang.Class.getConstructor0(Unknown Source)
         at java.lang.Class.newInstance0(Unknown Source)
         at java.lang.Class.newInstance(Unknown Source)
         at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:151)
         ... 81 more
Caused by: java.lang.ClassNotFoundException: org.eclipse.swt.SWTError
         at 
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
(...)

I see UI stuff all over the place (like
'java.lang.NoClassDefFoundError:org/eclipse/ui/plugin/Abstra ctUIPlugin',
'java.lang.NoClassDefFoundError: org/eclipse/debug/ui/RefreshTab', and
'An error occurred while automatically activating bundle
org.eclipse.debug.ui'). It looks like a simple workspace refresh is now
too much to ask... I think I must have installed to much
features/plugins into Buckminster, especially UI related ones?

My questions are: Does anyone have any experience with this kind of
builds? Does anyone know what to install into Buckminster and what not
to install? Are there any general hints you can give with regards to
Buckminster in combination with these technologies? Are there example
projects that also build projects with these technologies?

Any help would be greatly appreciated.

Thanks,
Dennis

Report message to a moderator

Re: Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects [message #546535 is a reply to message #546514]

Tue, 13 July 2010 09:59

Axel Guckelsberger

Messages: 354
Registered: July 2009

Senior Member

Hi Dennis,

I think best approach is to create bugs for corresponding projects about
separation of UI stuff.

See bug 315247 as one example I created for GMF. It refers to 315183 which
describes the problems I experienced with this one.

My current workaround is a bit dirty, but it seems to work until a better
solution arrives:
- use separate jobs in a CI system (e.g. Hudson)
- transfer the workspace between the jobs (different ways or plugins
available)
- use different headless Buckminster installations for them

I have one job for only creating stuff out from models (EMF, GMF). This uses
a separate Buckminster including the unwanted UI contributions. All
subsequent jobs use the other Buckminster which is really headless.

HTH
Axel

Dennis Hendriks wrote:

> Hello all,
>
> We use a lot of Eclipse Modeling Project technology (see subject of this
> post). I'm trying to create an update site using Buckminster, with
> Eclipse Helios, in headless mode.
>
> I did:
> - Install Buckminster headless using p2 director.
> - Install core/pde/subversive headless features into Buckminster.
> - Made an rmap and cquery to get my projects from SVN into the
> workspace.
> - Extended the EMF projects with a .spex and Ant build file to
> generate sources from the genmodel.
> - Created an update site from some feature that contains one of
> the EMF projects.
>
> I had some problems, like the Ecore2Java ant task not being found, so I
> installed org.eclipse.emf into Buckminster, and that solved the problem.
> I successfully created the p2 update site in headless mode. However, I
> installed all (or at least a large part) of EMF...
>
> So EMF is not a problem anymore, but the other types of projects I can't
> figure out. For instance, I need to run a .mwe2 file to generate a
> parser from my .xtext file. To this end I created a launch configuration
> that runs the MWE2 file. It works from within my normal (non-headless)
> Eclipse UI. However, it didn't in headless Buckminster. It couln't find
> 'org.eclipse.emf.mwe2.launch.Mwe2LaunchConfigurationType'. So, I
> installed all featuers with 'mwe' and 'xtext' in the name into
> Buckminster as well. Now I get new errors:
>
>
>

> ERROR: Error logged from Debug Core:
> org.eclipse.core.runtime.CoreException: Plug-in org.eclipse.debug.ui was
> unable to load class org.eclipse.debug.internal.ui.sourcelookup.Prompter.
>          at
> 
org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.throwException(RegistryStrategyOSGI.java:194)
>          at
> (...)
> Caused by:
> 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException:
> An error occurred while automatically activating bundle
> org.eclipse.debug.ui (113).
>          at
> 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:121)
>          at
> (...)
> Caused by: org.osgi.framework.BundleException: The activator
> org.eclipse.debug.internal.ui.DebugUIPlugin for bundle
> org.eclipse.debug.ui is invalid
>          at
> 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:156)
> (...)
> Caused by: java.lang.NoClassDefFoundError:
> org/eclipse/ui/plugin/AbstractUIPlugin
>          at java.lang.ClassLoader.defineClass1(Native Method)
>          at java.lang.ClassLoader.defineClass(Unknown Source)
> (...)
> Caused by:
> 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException:
> An error occurred while automatically activating bundle
> org.eclipse.ui.workbench (156).
> (...)
> Caused by: org.osgi.framework.BundleException: The activator
> org.eclipse.ui.internal.WorkbenchPlugin for bundle
> org.eclipse.ui.workbench is invalid
>          at
> 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:156)
> (...)
> Caused by: java.lang.NoClassDefFoundError: org/eclipse/swt/SWTError
>          at java.lang.Class.getDeclaredConstructors0(Native Method)
>          at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
>          at java.lang.Class.getConstructor0(Unknown Source)
>          at java.lang.Class.newInstance0(Unknown Source)
>          at java.lang.Class.newInstance(Unknown Source)
>          at
> 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:151)
>          ... 81 more
> Caused by: java.lang.ClassNotFoundException: org.eclipse.swt.SWTError
>          at
> 
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
> (...)
> Doing full workspace refresh
> Waiting for jobs to end
> java.lang.NoClassDefFoundError: org/eclipse/debug/ui/RefreshTab
>          at
> 
org.eclipse.emf.mwe2.launch.shortcut.Mwe2LaunchDelegate.launch(Mwe2LaunchDelegate.java:25)
>          at
> 
org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:853)
>          at
> 
org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:702)
>          at
> 
org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:695)
>          at
> org.eclipse.buckminster.core.commands.Launch.internalRun(Launch.java:192)
>          at
> 
org.eclipse.buckminster.core.commands.WorkspaceCommand.run(WorkspaceCommand.java:91)
>          at
> 
org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(AbstractCommand.java:194)
>          at
>          org.eclipse.buckminster.cmdline.Headless.run(Headless.java:317)
>          at
>          org.eclipse.buckminster.cmdline.Headless.run(Headless.java:136)
>          at
> org.eclipse.buckminster.cmdline.Headless.start(Headless.java:156)
>          at
> 
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> (...)
> Caused by:
> 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException:
> An error occurred while automatically activating bundle
> org.eclipse.debug.ui (113).
>          at
> 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:121)
>          at
> 
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453)
> (...)
> Caused by: org.osgi.framework.BundleException: The activator
> org.eclipse.debug.internal.ui.DebugUIPlugin for bundle
> org.eclipse.debug.ui is invalid
>          at
> 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:156)
> (...)
> Caused by: java.lang.NoClassDefFoundError:
> org/eclipse/ui/plugin/AbstractUIPlugin
>          at java.lang.ClassLoader.defineClass1(Native Method)
>          at java.lang.ClassLoader.defineClass(Unknown Source)
> (...)
> Caused by:
> 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException:
> An error occurred while automatically activating bundle
> org.eclipse.ui.workbench (156).
>          at
> 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:121)
> (...)
> Caused by: org.osgi.framework.BundleException: The activator
> org.eclipse.ui.internal.WorkbenchPlugin for bundle
> org.eclipse.ui.workbench is invalid
>          at
> 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:156)
> (...)
> Caused by: java.lang.NoClassDefFoundError: org/eclipse/swt/SWTError
>          at java.lang.Class.getDeclaredConstructors0(Native Method)
>          at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
>          at java.lang.Class.getConstructor0(Unknown Source)
>          at java.lang.Class.newInstance0(Unknown Source)
>          at java.lang.Class.newInstance(Unknown Source)
>          at
> 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:151)
>          ... 81 more
> Caused by: java.lang.ClassNotFoundException: org.eclipse.swt.SWTError
>          at
> 
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
> (...)
>

>
>
> I see UI stuff all over the place (like
> 'java.lang.NoClassDefFoundError:org/eclipse/ui/plugin/Abstra ctUIPlugin',
> 'java.lang.NoClassDefFoundError: org/eclipse/debug/ui/RefreshTab', and
> 'An error occurred while automatically activating bundle
> org.eclipse.debug.ui'). It looks like a simple workspace refresh is now
> too much to ask... I think I must have installed to much
> features/plugins into Buckminster, especially UI related ones?
>
> My questions are: Does anyone have any experience with this kind of
> builds? Does anyone know what to install into Buckminster and what not
> to install? Are there any general hints you can give with regards to
> Buckminster in combination with these technologies? Are there example
> projects that also build projects with these technologies?
>
> Any help would be greatly appreciated.
>
> Thanks,
> Dennis

Report message to a moderator

Re: Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects [message #546536 is a reply to message #546514]

Tue, 13 July 2010 10:02

Johannes Utzig

Messages: 329
Registered: July 2009

Senior Member

Am 13.07.2010 11:02, schrieb Dennis Hendriks:

Hi Dennis,

>
> My questions are: Does anyone have any experience with this kind of
> builds? Does anyone know what to install into Buckminster and what not
> to install? Are there any general hints you can give with regards to
> Buckminster in combination with these technologies? Are there example
> projects that also build projects with these technologies?
>

I do a lot of EMF, GMF, Xtext,... based build with buckminster, but I
usually commit the generated source to the SCM because we heavily modify
it, so I don't face that problem.
It's generally not a good idea to install the UI stuff into buckminster.
You need to figure out what bundles for example the MWE builder depends
on and if all of them are headless. If not, it really is a bug in MWE
for instance.

Best regards,
Johannes

Report message to a moderator

Re: Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects [message #546693 is a reply to message #546536]

Tue, 13 July 2010 19:15

Miles Parker

Messages: 1341
Registered: July 2009

Senior Member

Johannes Utzig wrote on Tue, 13 July 2010 06:02

I do a lot of EMF, GMF, Xtext,... based build with buckminster, but I
usually commit the generated source to the SCM because we heavily modify
it, so I don't face that problem.

Yes, I was sort of wondering what the use case is for doing all of this generation at build time. It seems like over kill to me generally, and you also have to be concerned about breaking changes to generated code. Finally, you then have to commit the changes back to source -- unless the generated code never ends up in source at all, but that would carry it's own problems. But I'm sure there are cases where it makes sense to do this. Smile

Report message to a moderator

Re: Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects [message #546751 is a reply to message #546693]

Wed, 14 July 2010 06:03

Eclipse User

Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl

Hello Miles,

for instance for our .ecore files, we have .genmodel files without any
changes. From the .genmodel, we generate the model/edit/editor code,
also without any custom changes. It therefore would only clutter our SVN
if we were to commit them to the repository.

The same goes for the parser/editor/ecore generated by Xtext, we have
not a single line of custom code.

For GMF however, we have quite some custom code, and therefore we
committed those files to SVN.

Best,
Dennis

Miles Parker wrote:
> Johannes Utzig wrote on Tue, 13 July 2010 06:02
>> I do a lot of EMF, GMF, Xtext,... based build with buckminster, but I
>> usually commit the generated source to the SCM because we heavily
>> modify it, so I don't face that problem.
>
>
> Yes, I was sort of wondering what the use case is for doing all of this
> generation at build time. It seems like over kill to me generally, and
> you also have to be concerned about breaking changes to generated code.
> Finally, you then have to commit the changes back to source -- unless
> the generated code never ends up in source at all, but that would carry
> it's own problems. But I'm sure there are cases where it makes sense to
> do this. :)

Report message to a moderator

Re: Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects [message #546801 is a reply to message #546751]

Wed, 14 July 2010 09:12

Axel Guckelsberger

Messages: 354
Registered: July 2009

Senior Member

Hello,

we are generating everything during the builds, as we inject all custom code
parts with custom templates. So we are versioning the models and the custom
templates which are building the actual "source".

Having the generated sources in SVN may cause some additional effort when
the DSL evolves and thus files structures change significantly.

Regards,
Axel

Dennis Hendriks wrote:

> Hello Miles,
>
> for instance for our .ecore files, we have .genmodel files without any
> changes. From the .genmodel, we generate the model/edit/editor code,
> also without any custom changes. It therefore would only clutter our SVN
> if we were to commit them to the repository.
>
> The same goes for the parser/editor/ecore generated by Xtext, we have
> not a single line of custom code.
>
> For GMF however, we have quite some custom code, and therefore we
> committed those files to SVN.
>
> Best,
> Dennis
>
>
> Miles Parker wrote:
>> Johannes Utzig wrote on Tue, 13 July 2010 06:02
>>> I do a lot of EMF, GMF, Xtext,... based build with buckminster, but I
>>> usually commit the generated source to the SCM because we heavily
>>> modify it, so I don't face that problem.
>>
>>
>> Yes, I was sort of wondering what the use case is for doing all of this
>> generation at build time. It seems like over kill to me generally, and
>> you also have to be concerned about breaking changes to generated code.
>> Finally, you then have to commit the changes back to source -- unless
>> the generated code never ends up in source at all, but that would carry
>> it's own problems. But I'm sure there are cases where it makes sense to
>> do this. :)

Report message to a moderator

Re: Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects [message #547255 is a reply to message #546514]

Fri, 16 July 2010 06:53

Daniel Weber

Messages: 51
Registered: July 2009

Member

Hi Dennis,

for this to work, you'll have to install features more selectively:

buckminster install http://download.eclipse.org/releases/helios org.eclipse.emf.converter
buckminster install http://download.eclipse.org/releases/helios org.eclipse.xtext.runtime

That way, you won't end up with all that UI stuff in your headless buckminster installation and generators should work. Since Xtext also uses EMFs Java generator, it might even be that org.eclipse.xtext.runtime already includes org.eclipse.emf.converter, I did not check that.

With these 2 features installed, I managed to get Ecore2Java as well as MWE workflows running headlessly :)

If you don't want to install from scratch, you can uninstall unwanted features using "uninstall":

buckminster uninstall <feature-spoiling-headless-mode>

Regards,
Daniel

P.S.: The same works for Galileo.

Report message to a moderator

Re: Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects [message #547273 is a reply to message #547255]

Fri, 16 July 2010 07:40

Eclipse User

Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl

Hello Daniel,

thanks for you reply.

If I install those two features, and compare the directories before and
after installing them, then grep to get anything that contains ui, but
not equinox, I get:

org.eclipse.emf.codegen.ecore.ui_2.6.0.v20100614-1136.jar
org.eclipse.emf.common.ui_2.6.0.v20100614-1136.jar
org.eclipse.emf.edit.ui_2.6.0.v20100614-1136.jar
org.eclipse.ltk.ui.refactoring_3.5.0.v20100526-0800.jar
org.eclipse.team.ui_3.5.100.I20100527-0800.jar
org.eclipse.ui_3.6.0.I20100603-1100.jar
org.eclipse.ui.editors_3.6.0.v20100520-0800.jar
org.eclipse.ui.forms_3.5.0.v20100427.jar
org.eclipse.ui.ide_3.6.0.I20100601-0800.jar
org.eclipse.ui.navigator_3.5.0.I20100601-0800.jar
org.eclipse.ui.views_3.5.0.I20100527-0800.jar
org.eclipse.ui.workbench_3.6.0.I20100603-1100.jar
org.eclipse.ui.workbench.texteditor_3.6.0.v20100520-0800.jar
org.eclipse.xtext.builder_1.0.0.v201006170321.jar
org.eclipse.xtext.ui_1.0.0.v201006170321.jar
org.eclipse.xtext.ui.junit_1.0.0.v201006170321.jar

In other words, those two features install the above plug-ins, which
look like user interface plug-ins to me. Things may work even with those
UI plug-ins installed, but it looks like the UI plug-ins are not
separated as well as they should be.

Also, for GMF projects, UI classes are obviously used. In order to
compile those Java files, you need to have some UI plug-ins installed. I
guess for GMF projects, there is no way around it...

Dennis

Daniel Weber wrote:
> Hi Dennis,
>
> for this to work, you'll have to install features more selectively:
>
> buckminster install http://download.eclipse.org/releases/helios
> org.eclipse.emf.converter
> buckminster install http://download.eclipse.org/releases/helios
> org.eclipse.xtext.runtime
>
> That way, you won't end up with all that UI stuff in your headless
> buckminster installation and generators should work. Since Xtext also
> uses EMFs Java generator, it might even be that
> org.eclipse.xtext.runtime already includes org.eclipse.emf.converter, I
> did not check that.
>
> With these 2 features installed, I managed to get Ecore2Java as well as
> MWE workflows running headlessly :)
>
> If you don't want to install from scratch, you can uninstall unwanted
> features using "uninstall":
>
> buckminster uninstall <feature-spoiling-headless-mode>
>
> Regards,
> Daniel
>
> P.S.: The same works for Galileo.

Report message to a moderator

Re: Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects [message #547285 is a reply to message #547273]

Fri, 16 July 2010 08:03

Daniel Weber

Messages: 51
Registered: July 2009

Member

Hi Dennis,

Dennis Hendriks wrote:
> [...]
> In other words, those two features install the above plug-ins, which
> look like user interface plug-ins to me. Things may work even with those
> UI plug-ins installed, but it looks like the UI plug-ins are not
> separated as well as they should be.

Agreed. I did not check which plugins are installed by these features,
I just tested if code generation works :) Seems like not every *.ui plugin
harms headless builds.

> Also, for GMF projects, UI classes are obviously used. In order to
> compile those Java files, you need to have some UI plug-ins installed. I
> guess for GMF projects, there is no way around it...

Well, I set up a PDE headless build a while ago, including GMF generation.
But I did not (yet) use GMF generation from buckminster. In order to compile
the generated GMF classes, having the required ui plugins in your target
platform should suffice. You won't have to install them into buckminster,
unless the GMF generator requires them.

Regards,
Daniel

Report message to a moderator

Re: Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects [message #547297 is a reply to message #547285]

Fri, 16 July 2010 08:58

Eclipse User

Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl

> Seems like not every *.ui plugin
> harms headless builds.

I agree.

> You won't have to install them into
> buckminster, unless the GMF generator requires them.

That's true. I forgot about that difference. Thanks for reminding me.

Dennis

Daniel Weber wrote:
> Hi Dennis,
>
> Dennis Hendriks wrote:
>> [...]
>> In other words, those two features install the above plug-ins, which
>> look like user interface plug-ins to me. Things may work even with
>> those UI plug-ins installed, but it looks like the UI plug-ins are not
>> separated as well as they should be.
>
> Agreed. I did not check which plugins are installed by these features, I
> just tested if code generation works :) Seems like not every *.ui plugin
> harms headless builds.
>
>> Also, for GMF projects, UI classes are obviously used. In order to
>> compile those Java files, you need to have some UI plug-ins installed.
>> I guess for GMF projects, there is no way around it...
>
> Well, I set up a PDE headless build a while ago, including GMF
> generation. But I did not (yet) use GMF generation from buckminster. In
> order to compile
> the generated GMF classes, having the required ui plugins in your target
> platform should suffice. You won't have to install them into
> buckminster, unless the GMF generator requires them.
>
> Regards,
> Daniel

Report message to a moderator

Re: Headless Buckminster and EMF/GMF/Xtext/QVTo/ATL/Xpand/Acceleo/EMFText projects [message #547418 is a reply to message #546751]

Fri, 16 July 2010 17:14

Miles Parker

Messages: 1341
Registered: July 2009

Senior Member

Eclipse User wrote on Wed, 14 July 2010 02:03

Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl
for instance for our .ecore files, we have .genmodel files without any
changes. From the .genmodel, we generate the model/edit/editor code,
also without any custom changes. It therefore would only clutter our SVN
if we were to commit them to the repository.

Hi Dennis,

As I mentioned in email that is a cool setup in the sense that you have an incredibly small set of artifacts driving the creation of a very large set of functionality, all automatically.

But I just came across another reason to like this pattern. I was working with the code for another systems EMF model and realized that I needed to regenerate it in order to creae some artifacts that hadn't been included. When I tried to do that I discovered that -- surprise! -- the result wouldn't compile because of a bunch of customizations and changes -- basically the code generation part of it hadn't been maintained so a lot of stuff was able to change in the code that shouldn't have. If they'd been forcing a regeneration every build that never could have happened.

cheers,

Miles

Report message to a moderator

Previous Topic:	org.eclipse.core.runtime.CoreException: Unable to read properties
Next Topic:	svn+ssh and svn provider

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 16 22:43:51 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter