Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Oomph » How to debug an Oomph setup model?
How to debug an Oomph setup model? [message #1764868] Fri, 02 June 2017 17:24 Go to next message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 438
Registered: March 2011
Senior Member
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.

Report message to a moderator

Re: How to debug an Oomph setup model? [message #1764895 is a reply to message #1764868] Sat, 03 June 2017 04:34 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33264
Registered: July 2009
Senior Member
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)...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: How to debug an Oomph setup model? [message #1778678 is a reply to message #1764895] Tue, 19 December 2017 19:49 Go to previous messageGo to next message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 438
Registered: March 2011
Senior Member
Thanks. Setting the execution environment, and adding org.eclipse.equinox.ds allows me to run the "Setup (Installer Dialog)" (still with the fragments for other platforms complaining). For "Setup (Installer Dialog Online)" I also had to add a bunch of org.apache.batik plugins.

However I still have other problems trying to debug. For the "Online" variant, I had to change the workspace location from @none to a real location, although it worked with @none in the other variant. But even after that, both variants fail with the error below, during the execution of the P2 Director task:

ERROR: org.eclipse.equinox.p2.metadata.repository code=1000 No repository found at file:/Users/epp/Development/PlasticOmnium/ides/oomph-master/git/org.eclipse.oomph/sites/org.eclipse.oomph.site/target/repository/.
  at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.fail(AbstractRepositoryManager.java:395)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:497)
  at org.eclipse.oomph.util.ReflectUtil.invokeMethod(ReflectUtil.java:117)
  at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.fail(CachingRepositoryManager.java:353)
  at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:244)
  at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager$Metadata.loadRepository(CachingRepositoryManager.java:476)
  at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96)
  at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92)
  at org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl$RepositoryLoader$Worker.perform(ProfileTransactionImpl.java:1613)
  at org.eclipse.oomph.util.WorkerPool$Worker.run(WorkerPool.java:428)
  at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)


The fact that the error mentions that there is a missing repository at

org.eclipse.oomph/sites/org.eclipse.oomph.site/target/repository/


made me think that perhaps I needed to build it with maven first (is this so?), but doing a "mvn clean install" fails early with

[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: org.eclipse.oomph.site raw:1.0.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):1.0.0-SNAPSHOT
[ERROR]   Missing requirement: org.eclipse.oomph.site raw:1.0.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):1.0.0-SNAPSHOT requires 'org.eclipse.oomph.all.source.feature.group 0.0.0' but it could not be found


So, what could be the missing repository problem? What do I need to do to debug a model?

Thanks

Report message to a moderator

Re: How to debug an Oomph setup model? [message #1778693 is a reply to message #1778678] Wed, 20 December 2017 08:11 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6693
Registered: July 2009
Senior Member
We build the repository with the following command line:

-Dbuild.id=Local
-Dgit.commit=Unknown
-DskipTests=true
-Denv=win64
-DGENERATE_SOURCE=true
clean
verify

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: How to debug an Oomph setup model? [SOLVED] [message #1778738 is a reply to message #1778693] Wed, 20 December 2017 15:35 Go to previous messageGo to next message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 438
Registered: March 2011
Senior Member
Great! Thanks. That works.

By the way, since I'm building on mac, I searched the POMs for the right env option, and I found two small anomalies. They are not a big deal, but you might want to take a look:

(commit a81f3f2c3d537e9a3af6d249c22e197839d02bfa)

In /org.eclipse.oomph.parent/pom.xml (lines 121-130) there are duplicated entries:

<environment>
  <os>win32</os>
  <ws>win32</ws>
  <arch>x86</arch>
</environment>
<environment>
  <os>win32</os>
  <ws>win32</ws>
  <arch>x86_64</arch>
</environment>


In /org.eclipse.oomph.setup.installer.product/pom.xml (lines 84-90) the name of the id (env-mac32) doesn't match the property value (mac64):

<id>env-mac32</id>
<activation>
  <property>
    <name>env</name>
    <value>mac64</value>
  </property>
</activation>

Report message to a moderator

Re: How to debug an Oomph setup model? [SOLVED] [message #1778766 is a reply to message #1778738] Thu, 21 December 2017 06:48 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6693
Registered: July 2009
Senior Member
Those entries are no duplicates. Mind the "_64" in the 64 bit environment.

I've fixed the wrong profile id in installer.product/pom.xml, although I'm sure the old value didn't cause any harm, either. Thanks for pointing it out!

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Previous Topic:Meaning of the * requirement
Next Topic:What does the "Requirements Update" dialog do?
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Dec 26 19:26:36 GMT 2024

Powered by FUDForum. Page generated in 0.03424 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly