[JBoss JIRA] (JBIDE-21340) Deploy from existing project git constraints are too stringent
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21340?page=com.atlassian.jira.plugi... ]
Fred Bricon reassigned JBIDE-21340:
-----------------------------------
Assignee: Andre Dietisheim
> Deploy from existing project git constraints are too stringent
> --------------------------------------------------------------
>
> Key: JBIDE-21340
> URL: https://issues.jboss.org/browse/JBIDE-21340
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Fred Bricon
> Assignee: Andre Dietisheim
> Labels: respin-a
> Fix For: 4.3.1.Beta1
>
>
> There are currently 2 constraints when deploying ane existing project to OpenShift 3 that are really really annoying:
> - if the project is shared with git but dirty, you can't proceed with project deployment on openshift. This constraint is completely unnecessary and should be lifted
> - if the project was cloned using git/ssh protocol, it can't be deployed directly (http(s) is required). This should actually just be a warning, the user can modify the git url to use http(s) in the next page
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21340) Deploy from existing project git constraints are too stringent
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21340?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-21340:
--------------------------------
Fix Version/s: 4.3.1.Beta1
> Deploy from existing project git constraints are too stringent
> --------------------------------------------------------------
>
> Key: JBIDE-21340
> URL: https://issues.jboss.org/browse/JBIDE-21340
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Fred Bricon
> Labels: respin-a
> Fix For: 4.3.1.Beta1
>
>
> There are currently 2 constraints when deploying ane existing project to OpenShift 3 that are really really annoying:
> - if the project is shared with git but dirty, you can't proceed with project deployment on openshift. This constraint is completely unnecessary and should be lifted
> - if the project was cloned using git/ssh protocol, it can't be deployed directly (http(s) is required). This should actually just be a warning, the user can modify the git url to use http(s) in the next page
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21340) Deploy from existing project git constraints are too stringent
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21340?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-21340:
--------------------------------
Labels: respin-a (was: )
> Deploy from existing project git constraints are too stringent
> --------------------------------------------------------------
>
> Key: JBIDE-21340
> URL: https://issues.jboss.org/browse/JBIDE-21340
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Fred Bricon
> Labels: respin-a
> Fix For: 4.3.1.Beta1
>
>
> There are currently 2 constraints when deploying ane existing project to OpenShift 3 that are really really annoying:
> - if the project is shared with git but dirty, you can't proceed with project deployment on openshift. This constraint is completely unnecessary and should be lifted
> - if the project was cloned using git/ssh protocol, it can't be deployed directly (http(s) is required). This should actually just be a warning, the user can modify the git url to use http(s) in the next page
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21340) Deploy from existing project git constraints are too stringent
by Fred Bricon (JIRA)
Fred Bricon created JBIDE-21340:
-----------------------------------
Summary: Deploy from existing project git constraints are too stringent
Key: JBIDE-21340
URL: https://issues.jboss.org/browse/JBIDE-21340
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.3.1.Beta1
Reporter: Fred Bricon
There are currently 2 constraints when deploying ane existing project to OpenShift 3 that are really really annoying:
- if the project is shared with git but dirty, you can't proceed with project deployment on openshift. This constraint is completely unnecessary and should be lifted
- if the project was cloned using git/ssh protocol, it can't be deployed directly (http(s) is required). This should actually just be a warning, the user can modify the git url to use http(s) in the next page
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21170) Virtualbox could not be found by CDK adapter
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21170?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-21170:
--------------------------------
Labels: (was: respin-a)
> 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
> Fix For: 4.3.1.Beta2
>
>
> 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, 3 months
[JBoss JIRA] (JBIDE-21170) Virtualbox could not be found by CDK adapter
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21170?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-21170:
--------------------------------
Labels: respin-a (was: )
> 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
> Fix For: 4.3.1.Beta2
>
>
> 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, 3 months
[JBoss JIRA] (JBIDE-21214) Domain modification via Credential preferences page doesn't work
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21214?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-21214:
-------------------------------------
This commit was made prior to branch. So it should be in the original beta1x, before the respin.
> Domain modification via Credential preferences page doesn't work
> ----------------------------------------------------------------
>
> Key: JBIDE-21214
> URL: https://issues.jboss.org/browse/JBIDE-21214
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core
> Affects Versions: 4.3.1.Beta1
> Environment: Fedora 22 KDE 64 bit
> Reporter: Vlado Pakan
> Assignee: Rob Stryker
> Fix For: 4.3.1.Beta1
>
>
> 1. Open Window > Preferences > JBoss Tools > Creddentials
> 2. Add Domain
> 3. Modify domain via Edit button and choose OK
> ERROR: Domain is not modified it shows previous domain name in prefences page
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21336) CDK cannot locate VBoxManage on MacOSX
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21336?page=com.atlassian.jira.plugi... ]
Xavier Coulon commented on JBIDE-21336:
---------------------------------------
right.
> CDK cannot locate VBoxManage on MacOSX
> --------------------------------------
>
> Key: JBIDE-21336
> URL: https://issues.jboss.org/browse/JBIDE-21336
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Xavier Coulon
> Assignee: Rob Stryker
> Fix For: 4.3.1.Beta2
>
>
> I get the following error message when starting the CDK Server Adapter on MacOSX (DevStudio was started from the dock, not from CLI):
> {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}
> when starting DevStudio from CLI, it inherits from the terminal PATH and then it works.
> We had a similar issue in Docker tooling ('docker-machine' needs to be in the PATH, as well as 'VBoxManage' or any other VM driver) so we ended up adding some preferences to set the correct path.
> That might be interesting to see how the Docker tooling, the Vagrant tooling and the CDK tooling could use the same preferences.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months