[JBoss JIRA] (JBIDE-21145) Component-install job does not reliably install all JBT IUs and so does not see changes between CI builds
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21145?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-21145:
------------------------------------
{quote}why keeping the composite builds?{quote}
In addition to it being a handy way to orchestrate running both the JBT core and core-tests jobs in parallel, it also verifies that the contents of the composite can be co-installed.
Sure, we have additional tests that do install tests downstream of the JBT aggregate build, but this is the *first-line verification* that we don't have some incomplete change (eg., an API change in Base that hasn't been absorbed by Server, or a change to JST which points to the wrong version of AngularJS).
And while it can be annoying sometimes when the job fails, it's better than relying on the install-grinder test, which is often broken for months w/o anyone repairing it. A 3-day problem is way better than a 30-day one, since people SEE it and complain. IMHO, the system is working because we blocked the build when a test failed.
Isn't that how test-driven dev is supposed to work? :D
> Component-install job does not reliably install all JBT IUs and so does not see changes between CI builds
> ---------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-21145
> URL: https://issues.jboss.org/browse/JBIDE-21145
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.1.Beta1, 4.4.0.Alpha1
> Reporter: Pavol Srna
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> We have often seen old artifacts on nightly sites (mars and neon too).
> It seems that the composite-install job [0], [1] is not reliable. So, the downstream JBT aggregate builds [2], [3] are not triggered automatically to pick up all new changes in the upstream JBT component site builds.
> [0] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-...
> [1] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-...
> [2] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-site... (latest build shows: "Nov 27, 2015 6:15 AM NOT PUBLISHED: UNCHANGED")
> [3] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-site... (latest build shows: "Nov 27, 2015 3:43 AM NOT PUBLISHED: UNCHANGED")
> Please investigate.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-16970) create mechanism to verify that nightly build is different from previous milestone
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16970?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-16970:
------------------------------------
True, diffing buildinfo.json requires that there's a previous buildinfo.json against which to diff.
But this is also true of a p2diff, since you need a previous update site URL against which to diff.
Or are you suggesting you could p2diff your local build against some OTHER local build? If we have another, older local p2 repo built locally, it will also contain a buildinfo.json file against which we could diff.
> create mechanism to verify that nightly build is different from previous milestone
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-16970
> URL: https://issues.jboss.org/browse/JBIDE-16970
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.2.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.x
>
>
> After the discovery site build job is done, we should:
> * get a list of JIRAs for a given target fixversion, eg., 4.2.0.Beta1 or 8.0.0.Beta1 *job param* milestone = Beta1, Beta2, CR1, Final/GA (special case)
> * for respins, use *job param* label = "respin-a" or "respin-b" in jira query
> * filter query to only show the components and map those to actual project names - see https://github.com/jbdevstudio/jbdevstudio-ci/blob/master/bin/createTaskJ... for mappings
> * install Eclipse from *job param* eclipseBundleVersion = luna.M6
> * install last milestone from *job param* oldURL = http://download.jboss.org/jbosstools/updates/staging/JBossTools-4.2.0.Bet...
> * install Eclipse from *job param* eclipseBundleVersion = luna.M6 (in a different folder)
> * install new nightly from *job param* oldURL = http://download.jboss.org/jbosstools/updates/nightlycore/4.2.luna/
> * compare installed footprints - see https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/instal...
> * run p2diff on the two repos - see https://github.com/irbull/p2diff
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21159) Cannot get SSL certificate
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21159?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-21159 at 12/3/15 8:15 AM:
-------------------------------------------------------------------
[~mlabuda] great, thanks for verifying. Resolving
was (Author: adietish):
[~mlabuda] great, thanks for verifying.
> Cannot get SSL certificate
> --------------------------
>
> Key: JBIDE-21159
> URL: https://issues.jboss.org/browse/JBIDE-21159
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Environment: openshift 3 tools 3.1.0.Beta1-v20151201-0140-B94
> Reporter: Jan Richter
> Assignee: Andre Dietisheim
> Priority: Blocker
> Labels: connection, openshift_v3
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> When trying to log into internal OSE instance, I can't retrieve certificate from the server, therefore it is not possible to establish a new connection. Internal OSE instance also requires to use parameter "--insecure-skip-tls-verify=true" while logging in from 'oc' binary because of some x509 obscurities.
> Stacktrace:
> {noformat}
> com.openshift.restclient.OpenShiftException: javax.net.ssl.SSLHandshakeException while trying to get an authorization context for server https://console.engint.openshift.com
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getContextUsingCredentials(AuthorizationClient.java:141)
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getAuthorizationDetails(AuthorizationClient.java:78)
> at com.openshift.internal.restclient.DefaultClient.getAuthorizationDetails(DefaultClient.java:496)
> at org.jboss.tools.openshift.internal.ui.wizard.connection.OAuthDetailView$AuthDetailsJob.run(OAuthDetailView.java:285)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:290)
> at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:259)
> at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:125)
> at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:319)
> at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363)
> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getContextUsingCredentials(AuthorizationClient.java:134)
> ... 4 more
> Caused by: java.security.cert.CertificateException: No X509TrustManager implementation available
> at sun.security.ssl.DummyX509TrustManager.checkServerTrusted(SSLContextImpl.java:1119)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491)
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21159) Cannot get SSL certificate
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21159?page=com.atlassian.jira.plugi... ]
Andre Dietisheim resolved JBIDE-21159.
--------------------------------------
Resolution: Done
> Cannot get SSL certificate
> --------------------------
>
> Key: JBIDE-21159
> URL: https://issues.jboss.org/browse/JBIDE-21159
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Environment: openshift 3 tools 3.1.0.Beta1-v20151201-0140-B94
> Reporter: Jan Richter
> Assignee: Andre Dietisheim
> Priority: Blocker
> Labels: connection, openshift_v3
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> When trying to log into internal OSE instance, I can't retrieve certificate from the server, therefore it is not possible to establish a new connection. Internal OSE instance also requires to use parameter "--insecure-skip-tls-verify=true" while logging in from 'oc' binary because of some x509 obscurities.
> Stacktrace:
> {noformat}
> com.openshift.restclient.OpenShiftException: javax.net.ssl.SSLHandshakeException while trying to get an authorization context for server https://console.engint.openshift.com
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getContextUsingCredentials(AuthorizationClient.java:141)
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getAuthorizationDetails(AuthorizationClient.java:78)
> at com.openshift.internal.restclient.DefaultClient.getAuthorizationDetails(DefaultClient.java:496)
> at org.jboss.tools.openshift.internal.ui.wizard.connection.OAuthDetailView$AuthDetailsJob.run(OAuthDetailView.java:285)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:290)
> at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:259)
> at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:125)
> at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:319)
> at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363)
> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getContextUsingCredentials(AuthorizationClient.java:134)
> ... 4 more
> Caused by: java.security.cert.CertificateException: No X509TrustManager implementation available
> at sun.security.ssl.DummyX509TrustManager.checkServerTrusted(SSLContextImpl.java:1119)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491)
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21159) Cannot get SSL certificate
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21159?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-21159:
------------------------------------------
[~mlabuda] great, thanks for verifying.
> Cannot get SSL certificate
> --------------------------
>
> Key: JBIDE-21159
> URL: https://issues.jboss.org/browse/JBIDE-21159
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Environment: openshift 3 tools 3.1.0.Beta1-v20151201-0140-B94
> Reporter: Jan Richter
> Assignee: Andre Dietisheim
> Priority: Blocker
> Labels: connection, openshift_v3
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> When trying to log into internal OSE instance, I can't retrieve certificate from the server, therefore it is not possible to establish a new connection. Internal OSE instance also requires to use parameter "--insecure-skip-tls-verify=true" while logging in from 'oc' binary because of some x509 obscurities.
> Stacktrace:
> {noformat}
> com.openshift.restclient.OpenShiftException: javax.net.ssl.SSLHandshakeException while trying to get an authorization context for server https://console.engint.openshift.com
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getContextUsingCredentials(AuthorizationClient.java:141)
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getAuthorizationDetails(AuthorizationClient.java:78)
> at com.openshift.internal.restclient.DefaultClient.getAuthorizationDetails(DefaultClient.java:496)
> at org.jboss.tools.openshift.internal.ui.wizard.connection.OAuthDetailView$AuthDetailsJob.run(OAuthDetailView.java:285)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:290)
> at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:259)
> at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:125)
> at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:319)
> at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363)
> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getContextUsingCredentials(AuthorizationClient.java:134)
> ... 4 more
> Caused by: java.security.cert.CertificateException: No X509TrustManager implementation available
> at sun.security.ssl.DummyX509TrustManager.checkServerTrusted(SSLContextImpl.java:1119)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491)
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21173) Runtime detection not working for CDK 2 Beta3
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21173?page=com.atlassian.jira.plugi... ]
Martin Malina edited comment on JBIDE-21173 at 12/3/15 5:49 AM:
----------------------------------------------------------------
Ok, thanks for the update, guys. I didn't know about the marker. and clearly CDK 2 Beta3 doesn't have it. So hopefully it will get included in future versions.
Alternatively, one could also use launchctl setenv PATH ....., but I don't think that's something we can do either.
was (Author: mmalina):
Ok, thanks for the update, guys. I didn't know about the marker. and clearly CDK 2 Beta3 doesn't have it. So hopefully it will get included in future versions.
> Runtime detection not working for CDK 2 Beta3
> ---------------------------------------------
>
> Key: JBIDE-21173
> URL: https://issues.jboss.org/browse/JBIDE-21173
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> When I point runtime detection to my cdk folder, it will not detect anything.
> I had the openshift.cdk feature installed.
> {code}
> nattura:features rasp$ ls|grep cdk
> org.jboss.tools.openshift.cdk.feature_3.1.0.Beta1-v20151202-0847-B100
> {code}
> And the runtime detection preference page shows that it will search for cdk runtimes
> (CDK is checked).
> The cdk in the folder that I use work fine when I add the adapter manually.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21170) Virtualbox could not be found by CDK adapter
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21170?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-21170:
---------------------------------------
BTW, here's a link describing how you can force launchd to use some path, but it's not really an option for us:
http://stackoverflow.com/questions/25385934/setting-environment-variables...
> Virtualbox could not be found by CDK adapter
> --------------------------------------------
>
> Key: JBIDE-21170
> URL: https://issues.jboss.org/browse/JBIDE-21170
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> After I set up a CDK server adapter and fixed the wrong path to vagrant in the launch config, I then started the server adapter and got this:
> Server CDK Server Adapter at localhost failed to start.
> Console:
> {code}
> The provider 'virtualbox' that was requested to back the machine
> 'default' is reporting that it isn't usable on this system. The
> reason is shown below:
> Vagrant could not detect VirtualBox! Make sure VirtualBox is properly installed.
> Vagrant uses the `VBoxManage` binary that ships with VirtualBox, and requires
> this to be available on the PATH. If VirtualBox is installed, please find the
> `VBoxManage` binary and add it to the PATH environmental variable.
> {code}
> Along with this, there was an Unhandled event loop exception in the error view:
> {code}
> org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException)
> at org.eclipse.swt.SWT.error(SWT.java:4491)
> at org.eclipse.swt.SWT.error(SWT.java:4406)
> at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4024)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3700)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
> 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:520)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
> Caused by: java.lang.NullPointerException
> at org.jboss.tools.central.editors.GettingStartedHtmlPage.updateEarlyAccess(GettingStartedHtmlPage.java:359)
> at org.jboss.tools.central.editors.GettingStartedHtmlPage.access$14(GettingStartedHtmlPage.java:342)
> at org.jboss.tools.central.editors.GettingStartedHtmlPage$6$1.run(GettingStartedHtmlPage.java:327)
> at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:162)
> at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:154)
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
> at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
> ... 23 more
> {code}
> In the command line, VBoxManage is accessible and it is located in /usr/local/bin/ and on my PATH.
> Max suggested I could try to start Eclipse from command line instead of double-clicking in Finder (which is the normal way to do it on Mac) and that helped.
> So for some reason when you start Eclipse using Eclipse.app from Finder, the PATH is incorrect.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months