[JBoss JIRA] (JBIDE-22171) Change to cdk launch config is not persisted
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22171?page=com.atlassian.jira.plugi... ]
Martin Malina updated JBIDE-22171:
----------------------------------
Priority: Minor (was: Major)
> Change to cdk launch config is not persisted
> --------------------------------------------
>
> Key: JBIDE-22171
> URL: https://issues.jboss.org/browse/JBIDE-22171
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.3.1.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Minor
> Fix For: 4.4.0.Alpha1
>
>
> I had a cdk server set up and I wanted to change it to point to another directory.
> So I opened the server editor, opened launch config, changed the Working Directory path, clicked Apply, OK, closed the server editor.
> But it turns out this changed was not persisted.
> If I open the launch config again, the old path is still there.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3635) Add the ability to detect/select existing dependencies/tools
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3635?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3635:
-------------------------------------
Additional approach to detect installed software on windows http://superuser.com/questions/447277/list-all-installed-software-on-pc
> Add the ability to detect/select existing dependencies/tools
> ------------------------------------------------------------
>
> Key: JBDS-3635
> URL: https://issues.jboss.org/browse/JBDS-3635
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer
> Reporter: Jan Richter
> Assignee: Denis Golovin
> Priority: Critical
> Labels: havoc, ui
> Fix For: 10.0.0.Alpha1
>
> Attachments: pdkinstaller.png, Technologies 5.pdf
>
>
> Generic rules for detection and validation are:
> 1. We do our best to detect what is installed on user's machine: vagrant, virtualbox, java and do not detect cdk, cygwin, or DevStudio;
> 2. When version is detected it must be verified against the range of what we believe valid versions; it might be defined as a set or condition.
> vagrant: minimal and tested version is 1.7.4, all newer releases are good to continue with warning except 1.8.0 which is known to have networking problems;
> virtualbox: minimal and tested 5.0.8 and all newer releases are good to continue with warning;
> jvm: minimal and tested is 1.8 and all newer releases are good to continue with warning;
> 3. For vagrant and virtual box if detected version is out of the range, installer shows error message with explanation and doesn't let go any further until detected version is uninstalled, which should be done manually and then installer should be restarted; If nothing is detected included versions can be installed or installer could be configured to use specific location;
> 4. For JVM if not supported version is detected, included one can be used or installer could be pointed to right location to use.
> 5. When location for required software set manually installer try will try detect version and verify it using (2);
> 6. When version cannot be detected and manually selected location looks like required install, installer should let to proceed with warning.
> It would be great if the installer allowed the user to use some of the required tools they have already installed.
> The idea is to detect if the dependencies are already present and let the user decide if they want to use them, or install new ones. Also, it could let the user select the tools themselves if they want to use a different installation than detected, etc.
> The confirmation page we currently have looks like the place to put all this, since it already displays most of the stuff that is going to get installed. Anyway, I have tried to modify it and squeeze the controls in and this is how the selection turned out (imagine the messages looking a bit smarter):
> !pdkinstaller.png|thumbnail!
> [~dgolovin] & [~crobson], what's your opinion on this?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBTIS-652) Adapt SAP tests according to the changes made in new Camel editor
by Tomáš Sedmík (JIRA)
[ https://issues.jboss.org/browse/JBTIS-652?page=com.atlassian.jira.plugin.... ]
Tomáš Sedmík closed JBTIS-652.
------------------------------
Fix Version/s: 4.3.0.CR1
Resolution: Done
PR was pushed to master branch
> Adapt SAP tests according to the changes made in new Camel editor
> -----------------------------------------------------------------
>
> Key: JBTIS-652
> URL: https://issues.jboss.org/browse/JBTIS-652
> Project: JBoss Tools Integration Stack
> Issue Type: Task
> Components: Fuse IDE, QE
> Affects Versions: 9.0.0.CR1
> Reporter: Andrej Podhradsky
> Assignee: Andrej Podhradsky
> Fix For: 4.3.0.CR1
>
>
> I'm still getting the following NPE when I try to add a component to the route
> {code}
> java.lang.NullPointerException
> at org.jboss.reddeer.gef.handler.EditPartHandler.getFigure(EditPartHandler.java:83)
> at org.jboss.reddeer.gef.impl.editpart.AbstractEditPart.getFigure(AbstractEditPart.java:89)
> at org.jboss.tools.fuse.reddeer.editor.CamelComponentEditPart.getBounds(CamelComponentEditPart.java:22)
> at org.jboss.tools.fuse.reddeer.editor.CamelEditor.getInEditorCoords(CamelEditor.java:608)
> at org.jboss.tools.fuse.reddeer.editor.CamelEditor.addCamelComponent(CamelEditor.java:150)
> at org.jboss.tools.fuse.ui.bot.test.SAPComponentTest.testSAPTRFCServer(SAPComponentTest.java:194)
> 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:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.reddeer.junit.internal.runner.statement.RunTestMethod.evaluate(RunTestMethod.java:36)
> at org.jboss.reddeer.junit.internal.runner.statement.RunBefores.evaluate(RunBefores.java:69)
> at org.jboss.reddeer.junit.internal.runner.statement.RunIBeforeTestExtensions.evaluate(RunIBeforeTestExtensions.java:63)
> at org.jboss.reddeer.junit.internal.runner.statement.RunAfters.evaluate(RunAfters.java:58)
> at org.jboss.reddeer.junit.internal.runner.statement.RunIAfterTestExtensions.evaluate(RunIAfterTestExtensions.java:51)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.jboss.reddeer.junit.internal.runner.RequirementsRunner.runChild(RequirementsRunner.java:165)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.jboss.reddeer.junit.internal.runner.statement.RunBefores.evaluate(RunBefores.java:69)
> at org.jboss.reddeer.junit.internal.runner.statement.FulfillRequirementsStatement.evaluate(FulfillRequirementsStatement.java:35)
> at org.jboss.reddeer.junit.internal.runner.statement.RunIBeforeClassExtensions.evaluate(RunIBeforeClassExtensions.java:60)
> at org.jboss.reddeer.junit.internal.runner.statement.RunAfters.evaluate(RunAfters.java:58)
> at org.jboss.reddeer.junit.internal.runner.statement.CleanUpRequirementStatement.evaluate(CleanUpRequirementStatement.java:34)
> at org.jboss.reddeer.junit.internal.runner.statement.RunIAfterClassExtensions.evaluate(RunIAfterClassExtensions.java:48)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.reddeer.junit.internal.runner.RequirementsRunner.run(RequirementsRunner.java:146)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.jboss.reddeer.eclipse.core.RemotePluginTestRunner.main(RemotePluginTestRunner.java:58)
> at org.jboss.reddeer.eclipse.core.UITestApplication.runTests(UITestApplication.java:115)
> at org.eclipse.e4.ui.internal.workbench.swt.E4Testable$1.run(E4Testable.java:73)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3798) Repeated component detection keeps stale values
by Jan Richter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3798?page=com.atlassian.jira.plugin.... ]
Jan Richter commented on JBDS-3798:
-----------------------------------
1. Go to confirm page.
2. Go back to target folder page.
3. Do something to vagrant/virtualbox that makes them unavailable
4. Go to confirm page again.
Now you should get both options for the component you've disabled and the 'use existing' is broken.
> Repeated component detection keeps stale values
> -----------------------------------------------
>
> Key: JBDS-3798
> URL: https://issues.jboss.org/browse/JBDS-3798
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 9.1.0.CR1
> Environment: Setup-bundled-0.0.2-20160413-107
> Reporter: Jan Richter
> Assignee: Denis Golovin
> Labels: havoc
> Attachments: screenshot-1.png
>
>
> Installer detects existing tools on confirmation page. If after that a change happens (like the user uninstalls VirtualBox) and then the user goes to the previous page and to confirm page again - the change is correctly detected, but instead of replacing the old option, there are now both options for 'install' and 'use existing'. Plus the count of detected components stays the same.
> Using the existing (no longer existing in fact) installation fails, naturally.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3653) User's home folder with spaces cannot be used by vagrant during install
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3653?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3653:
-------------------------------------
We will show warning at least. I also will check if we can workaround it .
> User's home folder with spaces cannot be used by vagrant during install
> -----------------------------------------------------------------------
>
> Key: JBDS-3653
> URL: https://issues.jboss.org/browse/JBDS-3653
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 9.1.0.Beta2
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Priority: Blocker
> Labels: havoc
> Fix For: 9.1.0.GA
>
> Attachments: install(1).log
>
>
> Vagrant complains about
> {quote}Wed, 02 Mar 2016 18:04:21 GMT-ERROR: cdk - Error: Command failed: C:\WINDOWS\system32\cmd.exe /s /c "vagrant plugin install c:\DeveloperPlatform\cdk\plugins\vagrant-registration-1.0.0.gem"
> The directory where plugins are installed (the Vagrant home directory)
> has a space in it. On Windows, there is a bug in Ruby when compiling
> plugins into directories with spaces. Please move your Vagrant home
> directory to a path without spaces and try again
> {quote}
> When user home directory have spaces in it, because .vagrant.d file path in turn has spaces as well. For instance:
> {code}C:\Users\User Name\.vagrant.d{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-22163) Allow to expose OpenShift 3 resource
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22163?page=com.atlassian.jira.plugi... ]
Marián Labuda resolved JBIDE-22163.
-----------------------------------
Fix Version/s: 4.3.1.CR1
(was: 4.4.x)
Resolution: Duplicate Issue
Yeah, you are right. Hard to keep track of all opened unresolved JIRAs. Closing this one as a duplicate.
> Allow to expose OpenShift 3 resource
> ------------------------------------
>
> Key: JBIDE-22163
> URL: https://issues.jboss.org/browse/JBIDE-22163
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Labels: openshift_v3
> Fix For: 4.3.1.CR1
>
>
> It would be nice to have exposing of OpenShift resources in our tooling. E.g. having a context menu item "Expose" in context menu of a resource - exposing a pod would create a service. Exposing a service would create a routing - same as it is for OpenShift command line client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3635) Add the ability to detect/select existing dependencies/tools
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3635?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3635:
-------------------------------------
I created new issue about what was done and linked it to this one. Moving this to 10.0.0.Alpha1 to continue work in next release.
> Add the ability to detect/select existing dependencies/tools
> ------------------------------------------------------------
>
> Key: JBDS-3635
> URL: https://issues.jboss.org/browse/JBDS-3635
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer
> Reporter: Jan Richter
> Assignee: Denis Golovin
> Priority: Critical
> Labels: havoc, ui
> Fix For: 10.0.0.Alpha1
>
> Attachments: pdkinstaller.png, Technologies 5.pdf
>
>
> Generic rules for detection and validation are:
> 1. We do our best to detect what is installed on user's machine: vagrant, virtualbox, java and do not detect cdk, cygwin, or DevStudio;
> 2. When version is detected it must be verified against the range of what we believe valid versions; it might be defined as a set or condition.
> vagrant: minimal and tested version is 1.7.4, all newer releases are good to continue with warning except 1.8.0 which is known to have networking problems;
> virtualbox: minimal and tested 5.0.8 and all newer releases are good to continue with warning;
> jvm: minimal and tested is 1.8 and all newer releases are good to continue with warning;
> 3. For vagrant and virtual box if detected version is out of the range, installer shows error message with explanation and doesn't let go any further until detected version is uninstalled, which should be done manually and then installer should be restarted; If nothing is detected included versions can be installed or installer could be configured to use specific location;
> 4. For JVM if not supported version is detected, included one can be used or installer could be pointed to right location to use.
> 5. When location for required software set manually installer try will try detect version and verify it using (2);
> 6. When version cannot be detected and manually selected location looks like required install, installer should let to proceed with warning.
> It would be great if the installer allowed the user to use some of the required tools they have already installed.
> The idea is to detect if the dependencies are already present and let the user decide if they want to use them, or install new ones. Also, it could let the user select the tools themselves if they want to use a different installation than detected, etc.
> The confirmation page we currently have looks like the place to put all this, since it already displays most of the stuff that is going to get installed. Anyway, I have tried to modify it and squeeze the controls in and this is how the selection turned out (imagine the messages looking a bit smarter):
> !pdkinstaller.png|thumbnail!
> [~dgolovin] & [~crobson], what's your opinion on this?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3635) Add the ability to detect/select existing dependencies/tools
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3635?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-3635:
--------------------------------
Fix Version/s: 10.0.0.Alpha1
(was: 9.1.0.GA)
> Add the ability to detect/select existing dependencies/tools
> ------------------------------------------------------------
>
> Key: JBDS-3635
> URL: https://issues.jboss.org/browse/JBDS-3635
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer
> Reporter: Jan Richter
> Assignee: Denis Golovin
> Priority: Critical
> Labels: havoc, ui
> Fix For: 10.0.0.Alpha1
>
> Attachments: pdkinstaller.png, Technologies 5.pdf
>
>
> Generic rules for detection and validation are:
> 1. We do our best to detect what is installed on user's machine: vagrant, virtualbox, java and do not detect cdk, cygwin, or DevStudio;
> 2. When version is detected it must be verified against the range of what we believe valid versions; it might be defined as a set or condition.
> vagrant: minimal and tested version is 1.7.4, all newer releases are good to continue with warning except 1.8.0 which is known to have networking problems;
> virtualbox: minimal and tested 5.0.8 and all newer releases are good to continue with warning;
> jvm: minimal and tested is 1.8 and all newer releases are good to continue with warning;
> 3. For vagrant and virtual box if detected version is out of the range, installer shows error message with explanation and doesn't let go any further until detected version is uninstalled, which should be done manually and then installer should be restarted; If nothing is detected included versions can be installed or installer could be configured to use specific location;
> 4. For JVM if not supported version is detected, included one can be used or installer could be pointed to right location to use.
> 5. When location for required software set manually installer try will try detect version and verify it using (2);
> 6. When version cannot be detected and manually selected location looks like required install, installer should let to proceed with warning.
> It would be great if the installer allowed the user to use some of the required tools they have already installed.
> The idea is to detect if the dependencies are already present and let the user decide if they want to use them, or install new ones. Also, it could let the user select the tools themselves if they want to use a different installation than detected, etc.
> The confirmation page we currently have looks like the place to put all this, since it already displays most of the stuff that is going to get installed. Anyway, I have tried to modify it and squeeze the controls in and this is how the selection turned out (imagine the messages looking a bit smarter):
> !pdkinstaller.png|thumbnail!
> [~dgolovin] & [~crobson], what's your opinion on this?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years