[JBoss JIRA] (JBTIS-843) SwitchYard Tests sometimes fail due to unability to find CTab
by Tomáš Sedmík (JIRA)
[ https://issues.jboss.org/browse/JBTIS-843?page=com.atlassian.jira.plugin.... ]
Tomáš Sedmík closed JBTIS-843.
------------------------------
PR was pushed to master
> SwitchYard Tests sometimes fail due to unability to find CTab
> -------------------------------------------------------------
>
> Key: JBTIS-843
> URL: https://issues.jboss.org/browse/JBTIS-843
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: QE, switchyard
> Affects Versions: 4.3.1.Final
> Reporter: Andrej Podhradsky
> Assignee: Andrej Podhradsky
> Fix For: 4.3.2.CR1
>
>
> Sometimes the CTab cannot be activated due to SWITCHYARD-2907
> {code}
> org.jboss.reddeer.swt.exception.SWTLayerException: No matching widget found
> at org.jboss.reddeer.swt.wait.AbstractWait.timeoutExceeded(AbstractWait.java:157)
> at org.jboss.reddeer.swt.wait.AbstractWait.wait(AbstractWait.java:110)
> at org.jboss.reddeer.swt.wait.AbstractWait.(AbstractWait.java:75)
> at org.jboss.reddeer.swt.wait.AbstractWait.(AbstractWait.java:51)
> at org.jboss.reddeer.swt.wait.AbstractWait.(AbstractWait.java:39)
> at org.jboss.reddeer.swt.wait.WaitUntil.(WaitUntil.java:23)
> at org.jboss.reddeer.swt.lookup.WidgetLookup.activeWidget(WidgetLookup.java:71)
> at org.jboss.reddeer.swt.widgets.AbstractWidget.(AbstractWidget.java:30)
> at org.jboss.reddeer.swt.impl.ctab.AbstractCTabItem.(AbstractCTabItem.java:28)
> at org.jboss.reddeer.swt.impl.ctab.DefaultCTabItem.(DefaultCTabItem.java:79)
> at org.jboss.reddeer.swt.impl.ctab.DefaultCTabItem.(DefaultCTabItem.java:44)
> at org.jboss.reddeer.swt.impl.ctab.DefaultCTabItem.(DefaultCTabItem.java:35)
> at org.jboss.tools.switchyard.reddeer.editor.SwitchYardEditor.activateDesignTab(SwitchYardEditor.java:79)
> at org.jboss.tools.switchyard.reddeer.editor.SwitchYardEditor.(SwitchYardEditor.java:73)
> at org.jboss.tools.switchyard.reddeer.project.SwitchYardProject.openSwitchYardFile(SwitchYardProject.java:46)
> at org.jboss.tools.switchyard.ui.bot.test.ValidatorsTest.openSwitchYardFile(ValidatorsTest.java:63)
> {code}
> or
> {code}
> org.jboss.reddeer.core.exception.CoreLayerException: No matching widget found with Matcher matching when all matchers match: [Matcher matching widgets with text that without mnenomic matches: is "Domain", Matcher matching widget with the same type as or type extending class org.eclipse.swt.custom.CTabItem]
> class org.eclipse.swt.widgets.Shell
> at org.jboss.reddeer.common.wait.AbstractWait.timeoutExceeded(AbstractWait.java:173)
> at org.jboss.reddeer.common.wait.AbstractWait.wait(AbstractWait.java:126)
> at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:91)
> at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:61)
> at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:46)
> at org.jboss.reddeer.common.wait.WaitUntil.<init>(WaitUntil.java:37)
> at org.jboss.reddeer.core.lookup.WidgetLookup.activeWidget(WidgetLookup.java:77)
> at org.jboss.reddeer.swt.widgets.AbstractWidget.<init>(AbstractWidget.java:31)
> at org.jboss.reddeer.swt.impl.ctab.AbstractCTabItem.<init>(AbstractCTabItem.java:28)
> at org.jboss.reddeer.swt.impl.ctab.DefaultCTabItem.<init>(DefaultCTabItem.java:87)
> at org.jboss.reddeer.swt.impl.ctab.DefaultCTabItem.<init>(DefaultCTabItem.java:47)
> at org.jboss.reddeer.swt.impl.ctab.DefaultCTabItem.<init>(DefaultCTabItem.java:37)
> at org.jboss.tools.switchyard.reddeer.editor.DomainEditor.activateDomainTab(DomainEditor.java:45)
> at org.jboss.tools.switchyard.reddeer.editor.DomainEditor.<init>(DomainEditor.java:40)
> at org.jboss.tools.switchyard.ui.bot.test.SwitchYardEditorDomainSettingsTest.securityConfigurationTest(SwitchYardEditorDomainSettingsTest.java:145)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23123) tooling blocks docker cert files even after cdk is stopped on Windows
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23123?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-23123:
-----------------------------------
Component/s: upstream
> tooling blocks docker cert files even after cdk is stopped on Windows
> ---------------------------------------------------------------------
>
> Key: JBIDE-23123
> URL: https://issues.jboss.org/browse/JBIDE-23123
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, docker, upstream
> Affects Versions: 4.4.1.Final
> Reporter: Martin Malina
> Assignee: Xavier Coulon
> Priority: Critical
>
> When you stop cdk in Eclipse, it does "vagrant halt" but it seems something still holds a lock on the docker cert files, because I can't do "vagrant destroy" from CLI.
> Steps:
> 1. Start cdk in Eclipse
> 2. Open Docker Explorer and expand to see the containers
> 3. Stop cdk in Eclipse
> 4. run "vagrant destroy" in CLI
> This will fail:
> {code}
> $ vagrant destroy
> default: Are you sure you want to destroy the 'default' VM? [y/N] y
> ==> default: Destroying VM and associated drives...
> C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/fileutils.rb:1444:in `rmdir': Directory not empty @ dir_s_rmdir - C:/mmalina/cdk2.2.rc3/cdk/components/rhel/rhel-ose/.vagrant/machines/default/virtualbox/docker (Errno::ENOTEMPTY)
> from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/fileutils.rb:1444:in `block in remove_dir1'
> from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/fileutils.rb:1458:in `platform_support'
> from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/fileutils.rb:1443:in `remove_dir1'
> from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/fileutils.rb:1436:in `remove'
> from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/fileutils.rb:778:in `block in remove_entry'
> from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/fileutils.rb:1493:in `postorder_traverse'
> from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/fileutils.rb:776:in `remove_entry'
> from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/fileutils.rb:634:in `block in rm_r'
> from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/fileutils.rb:630:in `each'
> from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/fileutils.rb:630:in `rm_r'
> from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/pathname.rb:575:in `rmtree'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:345:in `block in id='
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:343:in `each'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:343:in `id='
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/action/destroy.rb:12:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/action/forced_halt.rb:20:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builder.rb:116:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `block in run'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/busy.rb:19:in `busy'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `run'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/call.rb:53:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builder.rb:116:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `block in run'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/busy.rb:19:in `busy'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `run'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/call.rb:53:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/action/discard_state.rb:15:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builder.rb:116:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `block in run'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/busy.rb:19:in `busy'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `run'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/call.rb:53:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/env_set.rb:19:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/provisioner_cleanup.rb:25:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builder.rb:116:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `block in run'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/busy.rb:19:in `busy'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `run'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/call.rb:53:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builder.rb:116:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `block in run'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/busy.rb:19:in `busy'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `run'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/call.rb:53:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/Users/rasp/.vagrant.d/gems/gems/vagrant-registration-1.3.0/lib/vagrant-registration/action/unregister_on_destroy.rb:29:in `rescue in call'
> from C:/Users/rasp/.vagrant.d/gems/gems/vagrant-registration-1.3.0/lib/vagrant-registration/action/unregister_on_destroy.rb:14:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builder.rb:116:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `block in run'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/busy.rb:19:in `busy'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `run'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:224:in `action_raw'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:199:in `block in action'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:561:in `lock'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:185:in `call'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:185:in `action'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/commands/destroy/command.rb:31:in `block in execute'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:235:in `block in with_target_vms'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:229:in `each'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:229:in `with_target_vms'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/commands/destroy/command.rb:30:in `execute'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/cli.rb:42:in `execute'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:302:in `cli'
> from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/bin/vagrant:174:in `<main>'
> {code}
> It simply cannot remove /rhel-ose/.vagrant/machines/default/virtualbox/docker which contains the certificates for docker connection.
> Note that without step 2. this works, so it may actually be docker tooling who's at fault here.
> Environment:
> devstudio 10.1.0.GA B5921
> cdk 2.2 rc3
> Windows 10 x64
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23132) When ftl file is opened in devstudio/eclipse it does not get cursor/focus
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23132?page=com.atlassian.jira.plugi... ]
Alexey Kazakov reassigned JBIDE-23132:
--------------------------------------
Assignee: Daniel Dekany (was: Alexey Kazakov)
> When ftl file is opened in devstudio/eclipse it does not get cursor/focus
> -------------------------------------------------------------------------
>
> Key: JBIDE-23132
> URL: https://issues.jboss.org/browse/JBIDE-23132
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: freemarker
> Affects Versions: 4.4.1.Final
> Environment: Fedora 24, x86_64, devstudio:
> Version: 10.1.0.GA
> Build id: GA-v20160902-1725-B43
> Eclipse neon 1, RC1
> Reporter: Ondrej Dockal
> Assignee: Daniel Dekany
>
> When I open a freemarker file (.ftl) in devstudio (project/package explorer), new tab with editor is opened, but there is missing a cursor and I cannot actually set the cursor in calling setCursorPosition and thus, opening of content assistant throws a timeoutexception. It looks like editor is not focused.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23039) Need an interactive terminal that fits specific requirements
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23039?page=com.atlassian.jira.plugi... ]
Alexey Kazakov commented on JBIDE-23039:
----------------------------------------
I shouldn't have squash them. My fault.
> Need an interactive terminal that fits specific requirements
> ------------------------------------------------------------
>
> Key: JBIDE-23039
> URL: https://issues.jboss.org/browse/JBIDE-23039
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.4.1.AM2
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.4.2.AM1
>
> Attachments: vagranttty.png
>
>
> CDK Tools requires a terminal that allows interactivity of i/o. The full set of requirements is a bit difficult to find a solution for.
> 1) I must be able to get a Process or IProcess object when a command is run
> 2) I must be able to get an event or know when the process terminates
> 3) The terminal or console must be interactive and allow user input when prompted.
> 4) It must behave as in 3) for 'vagrant' commands and any and all associated plugins.
> These three requirements thus far seem impossible to solve. Solutions that have been attempted are:
> 1) Creating a java Process by myself via Runtime.exec. The interactive prompts never arrive and there is no API for Process to know when it is waiting for input.
> 2) Using the external-tools launch configuration. When running a command like mvn, the console that pops up seems to allow input from the user, and functions as expected. However, when running a command such as vagrant, such prompts are not provided. In our usecase, the following behavior is observed:
> a) During vagrant-registration prompts, the console indicates it is not a TTY terminal and cannot allow input
> b) During a landrush prompt for superuser status, no prompt is made, no TTY message is listed, and the process appears to have frozen
> 3) Launching / Opening a tm.terminal view. This solution fails requirements 1 and 2. We are not able to get a Process or an IProcess when a command is launched in a proper interactive terminal. This means we can have no way to know when the process has completed.
> Other options have been explored but ended up at dead ends and not worth mentioning. The real question is why interactive behavior is visible when using external-tools launch config for maven, but is not visible when running vagrant.
> Is this a function of the way the vagrant commands display or prompt for input? Why does vagrant-registration require a TTY terminal, but maven does not? Is this something that can be fixed upstream?
> No other obvious solutions have presented themselves in the past year.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22912) Deploy Docker Wizard: Inappropriate project combo size
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22912?page=com.atlassian.jira.plugi... ]
Snjezana Peco edited comment on JBIDE-22912 at 9/6/16 3:56 PM:
---------------------------------------------------------------
{quote}
i just checkouted your PR. If there is nothing else to do, i checked git checkout - it checkouted all your changes. In the beginning of my video you can see the main changes from your PR
{quote}
The main changes are the following:
https://github.com/jbosstools/jbosstools-openshift/pull/1302/commits/ee8b...
and
https://github.com/jbosstools/jbosstools-openshift/pull/1302/commits/ee8b...
The READ_ONLY flag or grid layout data in Combo cause the issue. The code you have shown helps when a page is displayed the first time, but has no influence on the issues occurring when resizing a wizard.
The patch behaves similarly to when we remove the line
{code}
combo.setLayoutData(gd);
{code}
from the snippet above. You can test the snippet with and without this this line.
was (Author: snjeza):
{quote}
i just checkouted your PR. If there is nothing else to do, i checked git checkout - it checkouted all your changes. In the beginning of my video you can see the main changes from your PR
{quote}
The main changes are the following:
https://github.com/jbosstools/jbosstools-openshift/pull/1302/commits/ee8b...
and
https://github.com/jbosstools/jbosstools-openshift/pull/1302/commits/ee8b...
The READ_ONLY flag or grid layout data in Combo cause the issue. The code you have shown helps when a page is displayed the first time, but has no influence on the issues occurring when resizing a wizard.
The patch behaves similarly to when we remove the line
{code}
combo.setLayoutData(gd);
{code}
from the snippet above.
> Deploy Docker Wizard: Inappropriate project combo size
> ------------------------------------------------------
>
> Key: JBIDE-22912
> URL: https://issues.jboss.org/browse/JBIDE-22912
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Environment: Fedora 24, GTK 3
> Reporter: Marián Labuda
> Assignee: Snjezana Peco
> Priority: Minor
> Labels: deploy_docker_wizard, openshift_v3
> Fix For: 4.4.2.AM1
>
> Attachments: dbocharov_inapproperiateComboSize.webm, deploy-to-docker-wizard-fc23.png, project_combo.png
>
>
> In Deploy Docker Image wizard opened from context menu of a docker image is project combo stretched to left size and it does not look good.
> !project_combo.png!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months