[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:
---------------------------------------
[~rob.stryker], thanks for the link.
So yeah, the important thing is what kind of PATH the launchd daemon has - it launches apps in OS X when you double click something in Finder or start something from Docker.
The article says that it's set up in /etc/launchd.conf, but this no longer applies - in El Capitan, there is no such file and I couldn't find it anywhere else.
But this command should be able to get the PATH:
launchctl getenv PATH
Unfortunately, the output is empty, which seems like there is no PATH at all.
So I'm wondering how we can overcome this. Could we inject our own path to the vagrant process that we start from Eclipse? We could then use some default PATH that would suite most users. (I think it's vagrant itself trying to call VBoxManage, not Eclipse, right?)
> 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
[JBoss JIRA] (JBIDE-20442) Create SWTBot integration tests for tern related features
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20442?page=com.atlassian.jira.plugi... ]
Denis Golovin edited comment on JBIDE-20442 at 12/3/15 4:16 AM:
----------------------------------------------------------------
*MODULES SET UP PROPERLY FOR HYBRID MOBILE PROJECT*
# Create new Hybrid Mobile Project
# ASSERT: Cordova JavaScript module is checked in JavaScript > Modules properties of Hybrid Mobile project
# Open www/js/index.js from created project
# ASSERT: cordova global variable available in content assist for empty line
# ASSERT: cordova.| shows content assist for cordova related properties
was (Author: vpakan):
*MODULES SET UP PROPERLY FOR HYBRID MOBILE PROJECT*
# Create new Hybrid Mobile Project
# ASSERT: Cordova JavaScript module is checked in JavaScript > Modules properties of Hybrid Mobile project
> Create SWTBot integration tests for tern related features
> ---------------------------------------------------------
>
> Key: JBIDE-20442
> URL: https://issues.jboss.org/browse/JBIDE-20442
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: jsp/jsf/xml/html-source-editing
> Affects Versions: 4.3.0.Beta2
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Priority: Critical
> Fix For: 4.3.x
>
>
> There should be set of SWTBot tests that would cover functionality related to tern.java and angularjs-eclipse integration. These tests would simplify migration to new tern.java and angularjs-eclipse releases.
> Current process for migration to new version of tern-java/angularjs-eclipse is manual. Steps below describe current approach:
> 1. Manual mirroring of latest tern-java/angularjs-eclipse versions to local filesystem;
> 2. Build jbosstools-jst with local mirrors and run JUnit tests;
> 3. Install latest tern-java and angularjs-eclipse form mirrors done in (1) into JBDS nightly build from master branch (it has open version range for tern features) and restart;
> 4. Run manual tests;
> 5. If (2) and (3) idenify no problems then local mirrors should be published to http://download.jboss.org/jbosstools/updates/requirements/tern and http://download.jboss.org/jbosstools/updates/requirements/angularjs respectively;
> 6. Update jbosstools-jst with new versions for tern-java/angularjs-eclipse and push local branch to upstream
> With step 4 implemented as SWT bot tests and automated mirroring for tern-java and angularjs-eclipse (see jenkins job here https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/All/job/jbosstools-...) we can fully automate the process above.
> QA also can skip step (1) and just use external p2 repos:
> * http://oss.opensagres.fr/tern.repository/1.0.0-SNAPSHOT/
> * http://oss.opensagres.fr/angularjs-eclipse/1.0.0-SNAPSHOT/
> in step (2) by building jbosstools-jst as:
> {code}mvn clean install -Dtern.repo.url=http://oss.opensagres.fr/tern.repository/1.0.0-SNAPSHOT/ -Dhttp://oss.opensagres.fr/angularjs-eclipse/1.0.0-SNAPSHOT/{code}
> and installing latest versions for step (3).
--
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 Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16970?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-16970:
---------------------------------------------
Another downside of relying on buildinfo.json to do these checks is that they rely on stuff only availble on jenkins or specific download.jboss.org servers (i.e. something have had to publish the .json file)
p2diff just needs the previous and newly built site, nothing else. Can even run 100% locally.
Also, if something went wrong in publish so the buildinfo.json is updated but the site failed to update - buildinfo.json would say stuff changed, but actually hadn't.
I'm not saying which is best - just saying relying on buildinfo.json is not the most obvious choice and could introduce even more coupling to specific systems making it harder to have our buildsetup be movable/scalable.
Thus just something to be aware and conscious about.
> 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 Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21159?page=com.atlassian.jira.plugi... ]
Marián Labuda commented on JBIDE-21159:
---------------------------------------
It seems to be fixed from latest nightly. I am not even observing issue Max has described. It works.
> 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 commented on JBIDE-21173:
---------------------------------------
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 Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21170?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-21170:
-------------------------------------
http://apple.stackexchange.com/questions/87282/in-mountain-lion-how-do-i-...
Maybe this will help?
> 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