[JBoss JIRA] (JBDS-3903) Platform Installer does not Setup Docker Env-Vars
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3903?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov updated JBDS-3903:
---------------------------------
Fix Version/s: (was: 10.1.0.GA)
> Platform Installer does not Setup Docker Env-Vars
> -------------------------------------------------
>
> Key: JBDS-3903
> URL: https://issues.jboss.org/browse/JBDS-3903
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Feature Request
> Components: docker
> Affects Versions: 10.0.0.Alpha1
> Environment: Windows
> Reporter: Thomas Mäder
> Assignee: Xavier Coulon
>
> I have installed CDK, etc. from the "all in one" installer. Later, I tried to use Docker tooling. I opened the view "Docker Explorer". There was no connection shown. I tried to add a new one, but the system did not detect my default connection.
> Later, I ran "Docker Quickstart Terminal" from the start menu. Now the "New Connection" dialog in docker explorer picked up the default connection.
> As a user, I have no indication that I have to run the docker terminal in order to use the docker tooling in eclipse. If there are environment variables to be set up, the installer should do so. It is the reasonable expectation on Windows.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23128) Eclipse Neon.1 Blog
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23128?page=com.atlassian.jira.plugi... ]
Ilya Buziuk updated JBIDE-23128:
--------------------------------
Sprint: devex #120 September 2016
> Eclipse Neon.1 Blog
> --------------------
>
> Key: JBIDE-23128
> URL: https://issues.jboss.org/browse/JBIDE-23128
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: javascript, upstream, website
> Reporter: Ilya Buziuk
> Assignee: Ilya Buziuk
> Fix For: 4.4.2.AM1
>
>
> Need to write blog about Neon.1 JSDT improvements. Tentative structure:
> - Node.js Debugger improvements
> - New JavaScript Debugger
> - npm scripts support
> - OMPH installer support
> - Important bug fixes (provide a query with all Neon.1 bug fixes)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ERT-358) Replace traces of old parser in Search/Indexing code. [EBZ#498371]
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/ERT-358?page=com.atlassian.jira.plugin.sy... ]
Ilya Buziuk updated ERT-358:
----------------------------
Sprint: devex #118 July 2016, devex #120 September 2016 (was: devex #118 July 2016)
> Replace traces of old parser in Search/Indexing code. [EBZ#498371]
> ------------------------------------------------------------------
>
> Key: ERT-358
> URL: https://issues.jboss.org/browse/ERT-358
> Project: Eclipse Release Train
> Issue Type: Task
> Components: JSDT
> Reporter: Friendly Jira Robot
> Assignee: Angel Misevski
> Priority: Trivial
> Labels: General, bzira
>
> Search and Indexing should be changed to use the newer dom ASTParser, instead of the old parser (e.g. in org.eclipse.wst.jsdt.internal.core.search.indexing.SourceIndexer).
> This needs to happen before any other improvements/refinements to JSDT Search.
> Looking at org.eclipse.wst.jsdt.internal.compiler.SourceElementParser, most of the class is using deprecated 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 Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23123?page=com.atlassian.jira.plugi... ]
Ilya Buziuk updated JBIDE-23123:
--------------------------------
Story Points: (was: 10)
> 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-23123) tooling blocks docker cert files even after cdk is stopped on Windows
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23123?page=com.atlassian.jira.plugi... ]
Ilya Buziuk updated JBIDE-23123:
--------------------------------
Story Points: 10
> 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-23016) When starting CDK 2.2 with landrush for the first time, user will be prompted for sudo password
by Lalatendu Mohanty (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23016?page=com.atlassian.jira.plugi... ]
Lalatendu Mohanty edited comment on JBIDE-23016 at 9/7/16 8:26 AM:
-------------------------------------------------------------------
[~akazakov] yes, that is equal to fresh installation. Make sure you also delete the .vagrant directory from the pwd of the Vagrant guest.
was (Author: lalatendum):
[~akazakov] yes, that is equal to fresh installation. Make sure you also delete the .vagrant directory from the PWD for the Vagrant guest.
> 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, 7 months
[JBoss JIRA] (JBIDE-23016) When starting CDK 2.2 with landrush for the first time, user will be prompted for sudo password
by Lalatendu Mohanty (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23016?page=com.atlassian.jira.plugi... ]
Lalatendu Mohanty edited comment on JBIDE-23016 at 9/7/16 8:25 AM:
-------------------------------------------------------------------
[~akazakov] yes, that is equal to fresh installation. Make sure you also delete the .vagrant directory from the PWD for the Vagrant guest.
was (Author: lalatendum):
[~akazakov] yes, that si equal to fresh installation. Make sure you also delete the .vagrant directory from the PWD for the Vagrant guest.
> 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, 7 months
[JBoss JIRA] (JBIDE-23016) When starting CDK 2.2 with landrush for the first time, user will be prompted for sudo password
by Lalatendu Mohanty (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23016?page=com.atlassian.jira.plugi... ]
Lalatendu Mohanty commented on JBIDE-23016:
-------------------------------------------
[~akazakov] yes, that si equal to fresh installation. Make sure you also delete the .vagrant directory from the PWD for the Vagrant guest.
> 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, 7 months