[JBoss JIRA] (JBTIS-896) Drools - Use Jira states for skipping some test cases which are supposed to fail
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBTIS-896?page=com.atlassian.jira.plugin.... ]
Andrej Podhradsky commented on JBTIS-896:
-----------------------------------------
Please have a look at org.jboss.tools.common.reddeer.condition.IssueIsClosed
> Drools - Use Jira states for skipping some test cases which are supposed to fail
> --------------------------------------------------------------------------------
>
> Key: JBTIS-896
> URL: https://issues.jboss.org/browse/JBTIS-896
> Project: JBoss Tools Integration Stack
> Issue Type: Task
> Components: drools/ jBPM, QE
> Affects Versions: 4.4.0.Alpha1
> Reporter: Andrej Podhradsky
> Assignee: Tomas David
> Fix For: 4.4.0.Alpha1
>
>
> Currently, smoke tests fail due to a known issue in drools plugin (DROOLS-1250). Please use an existing logic for checking Jira states so that we can skip the testing of Problems view (e.g. by setting reddeer.skipUnfixedIssues=true).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-22803) When OS projects are created and deleted, seems Openshift explorer restores non existing values
by Dmitrii Bocharov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22803?page=com.atlassian.jira.plugi... ]
Dmitrii Bocharov commented on JBIDE-22803:
------------------------------------------
[~jeffmaury], thank you! Finally could reproduce it too. Fedora 24
> When OS projects are created and deleted, seems Openshift explorer restores non existing values
> -----------------------------------------------------------------------------------------------
>
> Key: JBIDE-22803
> URL: https://issues.jboss.org/browse/JBIDE-22803
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.AM2
> Reporter: Jeff MAURY
> Assignee: Dmitrii Bocharov
> Labels: explorer, openshift, openshift_v3
> Fix For: 4.4.x
>
> Attachments: after application creation.png, after build finished.png, Openshift Web Console.png, screenshot-1.png
>
>
> EXEC: create an Openshift project
> EXEC: expand it
> EXEC: Create an application in this project (nodejs-example)
> ASSERT: wait for the pod to be available
> EXEC: delete the Openshit project
> EXEC: create an Openshift project (using the same name. You may have to repeat this step as you may got error that it still exists)
> EXEC: expand it
> EXEC: Create an application in this project (nodejs-example)
> EXEC: expand the nodejs-example node
> ASSERT: you should see 2 pods the old one and the build pod you just created: [^screenshot-1.png]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBTIS-897) UI is not refreshed after removing 'Event Definition' from 'Start Event'
by Jozef Marko (JIRA)
Jozef Marko created JBTIS-897:
---------------------------------
Summary: UI is not refreshed after removing 'Event Definition' from 'Start Event'
Key: JBTIS-897
URL: https://issues.jboss.org/browse/JBTIS-897
Project: JBoss Tools Integration Stack
Issue Type: Bug
Components: BPMN2
Affects Versions: 4.3.2.CR1
Reporter: Jozef Marko
Priority: Minor
If the _Event Definition_ is removed from _Start Event_ the UI is not refreshed and the _Start Event_ graphical representation still show presence of some _Event Definition_. After reopening of the process the start event is rendered correctly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBDS-4050) CDK 2.2 installation failed in devsuite 1.1.0-GA-20160915
by Budh Ram Gurung (JIRA)
[ https://issues.jboss.org/browse/JBDS-4050?page=com.atlassian.jira.plugin.... ]
Budh Ram Gurung commented on JBDS-4050:
---------------------------------------
Does cygwin install require packages like 'curl', 'zip', 'bsdtar', etc as part of installation in Devsuite ?
> CDK 2.2 installation failed in devsuite 1.1.0-GA-20160915
> ---------------------------------------------------------
>
> Key: JBDS-4050
> URL: https://issues.jboss.org/browse/JBDS-4050
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 10.1.0.GA
> Environment: **Operating System**
> Windows 10 Pro 64 Bit
> **Devsuite version**
> Devsuite 1.1.0-GA-20160915-140
> Reporter: Budh Ram Gurung
> Fix For: 10.2.0.AM1
>
> Attachments: 1.devsuite.PNG, 2.c++.PNG, 3.vagrant_cli.PNG, install-iteration1.log, install.log, vagrant-up-debug-log.txt
>
>
> After passing through registration, on clicking 'Install' button in the installer window, the CDK 2.2 get failed message.
> Check the attached screenshots.
> I also tried to add vagrant box through cygwin shell but getting some `eventmachine.so` related error.
> *NOTE*: I am able to successfully add the cdk box on Vagrant 1.7.4 version.
> Other information, I had following things pre-installed before running the installer:
> - Docker toolbox (probably it remain there when I was trying it last time)
> - Vagrant 1.8.1
> - Cygwin
> - VirtualBox 5.0.26
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23016) When starting CDK 2.2 with landrush for the first time, user will be prompted for sudo password
by Hardy Ferentschik (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23016?page=com.atlassian.jira.plugi... ]
Hardy Ferentschik commented on JBIDE-23016:
-------------------------------------------
{quote}
actually even if you're already logged in as an admin user on Windows, you still have to accept the admin permissions for the process. I would call this transparent as this is done by the OS and Eclipse do not have to support it in any way. But in my experience it is not true that as an admin there is no interaction needed - you won't need to enter your credentials, but you will still be prompted to accept this.
{quote}
It would be interesting to compare our Windows setups. For the VirtualBox changes I also get to accept a dialog, for the Landrush changes I don't provided I have admin privileges. You are saying that when Landrush makes its changes you get prompted with an dialog?
{quote}
And what about Windows?
{quote}
Easiest is probably to delete the whole network interface {{VBoxManage hostonlyif remove <interface name>}}. You can get a list of interfaces via {{netsh interface ip show config}}. Alternatively, you open the "view network connections" dialog. You need to select the interface which handles the IP of your VM. If you don't want to delete the interface you can open the TCP/IP settings for the appropriate interface in the "view network connections" dialog and select the DNS options. There delete the 127.0.0.1 as selected DNS server and switch the radio button back to automatic assigned DNS.
> When starting CDK 2.2 with landrush for the first time, user will be prompted for sudo password
> -----------------------------------------------------------------------------------------------
>
> Key: JBIDE-23016
> URL: https://issues.jboss.org/browse/JBIDE-23016
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.1.AM3
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.4.2.AM1
>
>
> The problem is that the first time you do vagrant up with cdk that has landrush set up, you will be asked to provide your sudo password so that landrush can be set up (unless you used it elsewhere already).
> This is definitely true on Mac, most likely on Linux also. On Windows, I expect that you will probably just be shown the system prompt for agreeing that the process uses admin rights.
> When I did this yesterday (while testing cdk 2.2 rc1), I actually started it from terminal first, so I could enter my password in the console. But I'm pretty sure this wouldn't work in Eclipse. So we need to figure out how to handle this scenario and also test what happens on Windows after installing devsuite and then starting cdk from devstudio - that is our most important use case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23123) tooling blocks docker cert files even after cdk is stopped on Windows
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23123?page=com.atlassian.jira.plugi... ]
Xavier Coulon updated JBIDE-23123:
----------------------------------
Fix Version/s: 4.5.x
> 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
> Fix For: 4.5.x
>
>
> 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, 6 months
[JBoss JIRA] (ERT-421) NPE when adding new Run Configuration for Run Docker Image [EBZ#501566]
by Friendly Jira Robot (JIRA)
Friendly Jira Robot created ERT-421:
---------------------------------------
Summary: NPE when adding new Run Configuration for Run Docker Image [EBZ#501566]
Key: ERT-421
URL: https://issues.jboss.org/browse/ERT-421
Project: Eclipse Release Train
Issue Type: Task
Components: Linux Tools
Reporter: Friendly Jira Robot
NPE is thrown when adding new Run Configuration for Run Docker Image if Docker Connection is not selected.
Steps to reproduce:
1. Install nightly Docker Tooling in Eclipse vanilla
2. Do not select/enable connection in Docker Explorer
3. Switch to Java Perspective
4. Restart eclipse
5. Run -> Run Configurations -> select Run Docker Image -> New Launch Configuration
6. An exception is thrown in Error Log:
Unhandled event loop exception
java.lang.NullPointerException
at org.eclipse.linuxtools.internal.docker.ui.wizards.ImageRunResourceVolumesVariablesModel.<init>(ImageRunResourceVolumesVariablesModel.java:93)
at org.eclipse.linuxtools.internal.docker.ui.launch.RunImageLaunchConfigurationTabGroup.createTabs(RunImageLaunchConfigurationTabGroup.java:48)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationTabGroupWrapper.createTabs(LaunchConfigurationTabGroupWrapper.java:141)
at org.eclipse.debug.internal.ui.launchConfigurations.CreateLaunchConfigurationAction.performAction(CreateLaunchConfigurationAction.java:75)
at org.eclipse.debug.internal.ui.launchConfigurations.AbstractLaunchConfigurationAction$1.run(AbstractLaunchConfigurationAction.java:107)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.debug.internal.ui.launchConfigurations.AbstractLaunchConfigurationAction.run(AbstractLaunchConfigurationAction.java:110)
at org.eclipse.ui.actions.BaseSelectionListenerAction.runWithEvent(BaseSelectionListenerAction.java:167)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:565)
at org.eclipse.jface.action.ActionContributionItem.lambda$5(ActionContributionItem.java:436)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5219)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1340)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4553)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4143)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:818)
at org.eclipse.jface.window.Window.open(Window.java:794)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationsDialog.open(LaunchConfigurationsDialog.java:1203)
at org.eclipse.debug.ui.DebugUITools$3.run(DebugUITools.java:629)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.debug.ui.DebugUITools.openLaunchConfigurationDialogOnGroup(DebugUITools.java:637)
at org.eclipse.debug.ui.DebugUITools.openLaunchConfigurationDialogOnGroup(DebugUITools.java:570)
at org.eclipse.debug.ui.actions.OpenLaunchDialogAction.run(OpenLaunchDialogAction.java:82)
at org.eclipse.debug.ui.actions.OpenLaunchDialogAction.runWithEvent(OpenLaunchDialogAction.java:91)
at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:237)
at org.eclipse.ui.internal.WWinPluginAction.runWithEvent(WWinPluginAction.java:228)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:565)
at org.eclipse.jface.action.ActionContributionItem.lambda$4(ActionContributionItem.java:397)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5219)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1340)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4553)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4143)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1121)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1022)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:150)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:687)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:604)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138)
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:388)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
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.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
at org.eclipse.equinox.launcher.Main.run(Main.java:1519)
at org.eclipse.equinox.launcher.Main.main(Main.java:1492)
Eclipse:
Eclipse SDK
Version: Neon.1 (4.6.1)
Build id: M20160907-1200
Docker Tooling:
2.2.0.201609142202
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBDS-4050) CDK 2.2 installation failed in devsuite 1.1.0-GA-20160915
by Budh Ram Gurung (JIRA)
[ https://issues.jboss.org/browse/JBDS-4050?page=com.atlassian.jira.plugin.... ]
Budh Ram Gurung edited comment on JBDS-4050 at 9/16/16 4:37 AM:
----------------------------------------------------------------
After performing above steps (clean uninstall and installation), I am still getting CDK 2.2 failure message.
After running the cygwin shell from installation directory, and trying to install vagrant box, I am getting error of "An error occurred while downloading the remote file".
Attached full vagrant-up-debug-log.txt and install-iteration1.txt files.
Also, found command `curl` is not present in devsuite's installed cygwin shell.
was (Author: budhrg):
After performing above steps (clean uninstall and installation), I am still getting CDK 2.2 failure message.
After running the cygwin shell from installation directory, and trying to install vagrant box, I am getting error of "An error occurred while downloading the remote file".
Attached full vagrant-up-debug-log.txt file.
Also, found command `curl` is not present in devsuite's installed cygwin shell.
> CDK 2.2 installation failed in devsuite 1.1.0-GA-20160915
> ---------------------------------------------------------
>
> Key: JBDS-4050
> URL: https://issues.jboss.org/browse/JBDS-4050
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 10.1.0.GA
> Environment: **Operating System**
> Windows 10 Pro 64 Bit
> **Devsuite version**
> Devsuite 1.1.0-GA-20160915-140
> Reporter: Budh Ram Gurung
> Fix For: 10.2.0.AM1
>
> Attachments: 1.devsuite.PNG, 2.c++.PNG, 3.vagrant_cli.PNG, install-iteration1.log, install.log, vagrant-up-debug-log.txt
>
>
> After passing through registration, on clicking 'Install' button in the installer window, the CDK 2.2 get failed message.
> Check the attached screenshots.
> I also tried to add vagrant box through cygwin shell but getting some `eventmachine.so` related error.
> *NOTE*: I am able to successfully add the cdk box on Vagrant 1.7.4 version.
> Other information, I had following things pre-installed before running the installer:
> - Docker toolbox (probably it remain there when I was trying it last time)
> - Vagrant 1.8.1
> - Cygwin
> - VirtualBox 5.0.26
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months