| How to debug an Oomph setup model? [message #1764868] |
Fri, 02 June 2017 13:24  |
Eclipse User |
|
|
|
Hi. I was wondering how to go about debugging a setup model. In the wiki (https://wiki.eclipse.org/Eclipse_Oomph_Authoring#Installing_Oomph) I found information on *testing* a model, but not on *debugging* Oomph itself running a model.
I installed a fresh Oomph SDK and created a setup model I want to debug. I found that
org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.initTriggeredSetupTasks(Stream, Phase)
and
org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTask(SetupTask, IProgressMonitor)
are probably good places to put breakpoints.
I also found three launch configurations that seem relevant:
1- Setup IDE
2- Setup (Installer Dialog Online)
3- Setup (Installer Dialog)
I imagine that #2 and #3 start the Installer. Will #1 execute the new IDE created for my model?
If I run #2 or #3 as Debug configurations, will the debugger still run on the new IDE?
I tried to get an answers for these, but running them failed.
For #1 I got the errors in the attached log errors_setup_ide_1496423791857.log.
For #2 I got the errors in the attached log errors_setup_installer_dialog_online_1496423592076.log.
For #3 I got the errors in the attached log errors_setup_installer_dialog_1496422945510.log.
When attempting #3 I get a Validation warning, where apparently a lot of bundles are missing dependencies, which suggests that the Oomph setup didn't install everything that's needed. Am I missing something here, or is this a bug in Oomph SDK setup?
Is there something I need to do to get these launch configurations running?
Thanks.
|
|
|
| Re: How to debug an Oomph setup model? [message #1764895 is a reply to message #1764868] |
Sat, 03 June 2017 00:34  |
| Eclipse User |
|
|
|
Unfortunately the launchers tend to grow stale. Much of that is because, in my opinion, their design is rather poor. The point is that they might have explicit bundle versions specified so that if we resolve a newer version of the target platform, they don't resolve properly. Also, there are tricky things especially for the installer launch where we need to minimize the number of plugins launched, so we make it feature-based, but then certain important plugins from p2 and especially org.eclipse.equinox.ds are missing so they need to be specifically added resulting in this in the *.launch:<setAttribute key="additional_plugins">
<setEntry value="org.eclipse.equinox.ds:1.5.0.v20170307-1429:default:true"/>
<setEntry value="org.eclipse.equinox.p2.artifact.repository:1.1.500.v20160419-0834:default:true"/>
<setEntry value="org.eclipse.equinox.p2.console:1.0.500.v20170105-1450:default:true"/>
<setEntry value="org.eclipse.equinox.p2.core:2.4.100.v20160419-0834:default:true"/>
<setEntry value="org.eclipse.equinox.p2.director.app:1.0.500.v20160419-0834:default:true"/>
<setEntry value="org.eclipse.equinox.p2.director:2.3.300.v20160504-1450:default:true"/>
<setEntry value="org.eclipse.equinox.p2.directorywatcher:1.1.100.v20150423-1455:default:true"/>
<setEntry value="org.eclipse.equinox.p2.discovery.compatibility:1.0.200.v20131211-1531:default:true"/>
<setEntry value="org.eclipse.equinox.p2.discovery:1.0.400.v20160504-1450:default:true"/>
<setEntry value="org.eclipse.equinox.p2.engine:2.5.0.v20170110-1705:default:true"/>
<setEntry value="org.eclipse.equinox.p2.extensionlocation:1.2.300.v20160419-0834:default:true"/>
<setEntry value="org.eclipse.equinox.p2.garbagecollector:1.0.300.v20160504-1450:default:true"/>
<setEntry value="org.eclipse.equinox.p2.jarprocessor:1.0.500.v20160504-1450:default:true"/>
<setEntry value="org.eclipse.equinox.p2.metadata.repository:1.2.300.v20170131-1152:default:true"/>
<setEntry value="org.eclipse.equinox.p2.metadata:2.3.100.v20170105-1450:default:true"/>
<setEntry value="org.eclipse.equinox.p2.operations:2.4.200.v20160830-1950:default:true"/>
<setEntry value="org.eclipse.equinox.p2.publisher.eclipse:1.2.100.v20170131-1152:default:true"/>
<setEntry value="org.eclipse.equinox.p2.publisher:1.4.100.v20160504-1450:default:true"/>
<setEntry value="org.eclipse.equinox.p2.reconciler.dropins:1.1.400.v20160504-1450:default:true"/>
<setEntry value="org.eclipse.equinox.p2.repository.tools:2.1.300.v20170110-0218:default:true"/>
<setEntry value="org.eclipse.equinox.p2.repository:2.3.200.v20170208-2010:default:true"/>
<setEntry value="org.eclipse.equinox.p2.touchpoint.eclipse:2.1.400.v20160419-0834:default:true"/>
<setEntry value="org.eclipse.equinox.p2.touchpoint.natives:1.2.100.v20170109-2036:default:true"/>
<setEntry value="org.eclipse.equinox.p2.transport.ecf:1.1.300.v20161004-0244:default:true"/>
<setEntry value="org.eclipse.equinox.p2.updatesite:1.0.600.v20160504-1450:default:true"/>
</setAttribute>
So if any of those change, the launch is broken again.
So definitely in each case it's important to use the Plug-ins tab to validate the plugins and to add p2 and equinox.ds until the launchers are in reasonable shape. Even then, for the installer there will remain complaints about fragments from other platform architectures not working; another bug in PDE in my opinion, i.e., how can one create a launcher that works on all platforms with a target platform that resolves all platforms?
Also, while Oomph itself doesn't require Java 8, or even Java 7, the Eclipse platform itself does, so you need to provision the workspace with a 1.8 JRE, even though the Oomph source code doesn't need that. Otherwise you won't be able to launch the Eclipse platform. You're logs suggest you might not have done that.
Sorry for the hassle. We really should at leave update the launchers to be valid with the latest Oxygen target platform (on Windows)...
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.11384 seconds
Home