[JBoss JIRA] (JBIDE-22578) Publishing sometimes recursively deletes parent to deploy directory
by Josef Kopriva (Jira)
[ https://issues.jboss.org/browse/JBIDE-22578?page=com.atlassian.jira.plugi... ]
Josef Kopriva closed JBIDE-22578.
---------------------------------
Closing as ^^ comments.
> Publishing sometimes recursively deletes parent to deploy directory
> -------------------------------------------------------------------
>
> Key: JBIDE-22578
> URL: https://issues.jboss.org/browse/JBIDE-22578
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.3.1.Final
> Environment: Eclipse Mars.2 Release (4.5.2)
> Java 1.8.0_91
> Windows 7 64-bit
> JBoss EAP 6.4.0
> Reporter: Daniel Atallah
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.12.0.Final
>
> Attachments: jboss_deployment.jpg, jboss_tools.20160630.stdout.log, servers.xml
>
>
> For a number of weeks we've had a number of occurrences where a eclipse workspace will get corrupted due to the deletion of all files in it.
> It seems to have started happening at the time we updated to the 4.3.1 JBoss Tools from the 4.3.0 JBoss Tools.
> We've been able to track the process doing the deleting to the Eclipse process by using Sysinternals Process Monitor tool (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx).
> Our workspaces are structured as follows:
> {noformat}
> WORKSPACEROOT=$DEVROOT\workspacename
> # Custom deploy folder (as specified in the "Deployment" settings for the configured "Red Hat JBoss Enterprise Application Platform 6.1+") Server
> $WORKSPACEROOT\deploy
> # Version Control (Mercurial) working directory containing various Eclipse projects that get published to the Server by the tooling
> $WORKSPACEROOT\src
> # value specified as a "jboss.server.data.dir" property in the Server launch configuration VM arguments
> $WORKSPACEROOT/server/data
> # value specified as a "jboss.server.temp.dir" property in the Server launch configuration VM arguments
> $WORKSPACEROOT/server/tmp
> {noformat}
> The Server is configured to "Automatically publish when resources change".
> What we're seeing is that occasionally when the Server is running and the Mercurial working copy receives updates, the Incremental Publishing that results from these updates somehow tries to recursively delete $WORKSPACEROOT.
> The eclipse log includes the following:
> {noformat}
> !ENTRY org.eclipse.core.resources 4 1 2016-06-07 16:05:57.795
> !MESSAGE Problems occurred refreshing resources
> !SUBENTRY 1 org.eclipse.core.resources 4 1 2016-06-07 16:05:57.795
> !MESSAGE Problem finding next change, code: 5
> !ENTRY org.jboss.ide.eclipse.as.core 4 1644298244 2016-06-07 16:06:09.207
> !MESSAGE Incremental publish failed for module $MODULENAME
> !SUBENTRY 1 org.jboss.ide.eclipse.as.wtp.core 4 1644298251 2016-06-07 16:06:09.207
> !MESSAGE Could not delete $WORKSPACEROOT. May be locked by another process.
> {noformat}
> Any idea what might be happening?
> Is there some debug logging we can enable to get better visibility to what's going on?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (JBIDE-26694) Server adapter: should be able to freely set a war name
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26694?page=com.atlassian.jira.plugi... ]
André Dietisheim edited comment on JBIDE-26694 at 7/16/19 2:54 AM:
-------------------------------------------------------------------
This now basically works, but there are 2 gotchas left:
* once the war name is changed, deployment to this new name is only done once you clean (ctx menu entry). (See here: https://youtu.be/p849a4mA1Gw)
* the old deployment is not removed
I suggest that we merge the current PR for this issue once it's tested and address those 2 issues in separate issues/PRs.
[~jkopriva]: CC
was (Author: adietish):
This now basically works, but there are 2 gotchas left:
* once the war name is changed, deployment to this new name is only done once you clean (ctx menu entry). (See here: https://youtu.be/p849a4mA1Gw)
* the old deployment is not removed
I suggest that we merge the current PR for this issue once it's tested and address those 2 issues in separate issues/PRs.
> Server adapter: should be able to freely set a war name
> -------------------------------------------------------
>
> Key: JBIDE-26694
> URL: https://issues.jboss.org/browse/JBIDE-26694
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.12.0.AM1
> Reporter: André Dietisheim
> Assignee: André Dietisheim
> Priority: Major
> Labels: server_adapter
> Fix For: 4.13.0.AM1
>
> Attachments: console-output-1.png, console-output-2.png, deployment-page-edit-war-name.png, server-adapter-configuration.png, switch-location.png
>
>
> For the server adapters in tools/as we have UI that allows a user to set the name of the deployment archive. We're missing this feature for the OpenShift server adapters currently. We're asked to add it.
> Steps:
> # EXEC: create a new app by using the *jboss-webserver31-tomcat8-openshift:1.2* builder image
> # ASSERT: *websocket-chat* application is imported into your workspace
> # ASSERT: server adapter *jboss-webserver31-tomcat* is created
> # ASSERT: In OpenShift explorer, below the service jboss-webserver31-tomcat*, you have the running pod (build is finished, pod running)
> # EXEC: start the server adapter
> # ASSERT: RSync is executed and the output is visible in the "Console"
> Result:
> If you look closely at the output you see that the project is synced to the pod in a folder called *websocket-chat.jar*
> !console-output-1.png!
> Expected result:
> I should be able to set the output folder to anything I want. Ex. we have a customer that wants the application war to be synced up into a folder *ROOT* (without the extension *.war*).
> Currently, to achieve this I have to do the following:
> # EXEC: create the following xml snippet (notice the *outputName* property for the module)
> and make sure it reads as follows:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <deployment>
> <local>
> <module id="org.eclipse.jst.jee.server:websocket-chat">
> <property key="tempLocation" value="" />
> <property key="location" value="" />
> <property key="outputName" value="ROOT" />
> </module>
> </local>
> </deployment>
> {code}
> # EXEC: html-encode, join it into a single line and copy it (into the clipboard)
> # EXEC: open the properties for the server adapter and hit "Switch Location"
> !switch-location.png!
> # ASSERT: in my workspace, a new project *Servers* is created. It contains the configuration for my server adapter.
> !server-adapter-configuration.png!
> # EXEC: open the file with the *XML Editor*
> # EXEC: in your *XML Editor*: go to the end of the line *<server auto-publish-setting="2"* and insert your html-encoded xml as a value to the attribute *org.jboss.ide.eclipse.as.core.util.deploymentPreferenceKey="*
> {code}
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <server auto-publish-setting="2" auto-publish-time="2" hostname="jboss-webserver31-tomcat-test.192.168.64.76.nip.io" id="test@jboss-webserver31-tomcat" id-set="true" name="jboss-webserver31-tomcat (Service) at OpenShift 3 (192.168.64.76)" org.jboss.ide.eclipse.as.core.server.IGNORE_LAUNCH_COMMANDS="true" org.jboss.ide.eclipse.as.core.server.deployDirectoryType="custom" org.jboss.ide.eclipse.as.core.server.serverMode="openshift3" org.jboss.ide.eclipse.as.core.server.webPort="80" org.jboss.ide.eclipse.as.core.server.webPortAutoDetect="false" org.jboss.ide.eclipse.as.core.server.zipDeploymentsPreference="true" org.jboss.tools.openshift.Connection="https://developer@192.168.64.76:8443" org.jboss.tools.openshift.DeployProject="websocket-chat" org.jboss.tools.openshift.PodPath="/opt/webserver/webapps" org.jboss.tools.openshift.SERVER_START_ON_CREATION="false" org.jboss.tools.openshift.Service="test@jboss-webserver31-tomcat" org.jboss.tools.openshift.SourcePath="${workspace_loc:/websocket-chat}" port="80" runtime-id="test@jboss-webserver31-tomcat" server-type="org.jboss.tools.openshift.server.type" server-type-id="org.jboss.tools.openshift.server.type" start-timeout="450" stop-timeout="450" timestamp="2" org.jboss.ide.eclipse.as.core.util.deploymentPreferenceKey="<?xml version="1.0" encoding="UTF-8"?> <deployment> <local> <module id="org.eclipse.jst.jee.server:websocket-chat"> <property key="tempLocation" value="" /> <property key="location" value="" /> <property key="outputName" value="ROOT" /> </module> </local> </deployment>">
> <list key="modules" value0="websocket-chat::org.eclipse.jst.jee.server:websocket-chat::jst.web::3.0"/>
> </server>
> {code}
> # EXEC: Save the editor and restart the server
> Result:
> Syncing now happens into a folder *ROOT*
> !console-output-2.png!
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (JBIDE-23123) tooling blocks docker cert files even after cdk is stopped on Windows
by Josef Kopriva (Jira)
[ https://issues.jboss.org/browse/JBIDE-23123?page=com.atlassian.jira.plugi... ]
Josef Kopriva closed JBIDE-23123.
---------------------------------
CDK 2.2 is not supported anymore, so closing.
> 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.12.0.Final
>
>
> 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
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (JBIDE-26694) Server adapter: should be able to freely set a war name
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26694?page=com.atlassian.jira.plugi... ]
André Dietisheim commented on JBIDE-26694:
------------------------------------------
This now basically works, but there are 2 gotchas left:
* once the war name is changed, deployment to this new name is only done once you clean (ctx menu entry). (See here: https://youtu.be/p849a4mA1Gw)
* the old deployment is not removed
I suggest that we merge the current PR for this issue once it's tested and address those 2 issues in separate issues/PRs.
> Server adapter: should be able to freely set a war name
> -------------------------------------------------------
>
> Key: JBIDE-26694
> URL: https://issues.jboss.org/browse/JBIDE-26694
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.12.0.AM1
> Reporter: André Dietisheim
> Assignee: André Dietisheim
> Priority: Major
> Labels: server_adapter
> Fix For: 4.13.0.AM1
>
> Attachments: console-output-1.png, console-output-2.png, deployment-page-edit-war-name.png, server-adapter-configuration.png, switch-location.png
>
>
> For the server adapters in tools/as we have UI that allows a user to set the name of the deployment archive. We're missing this feature for the OpenShift server adapters currently. We're asked to add it.
> Steps:
> # EXEC: create a new app by using the *jboss-webserver31-tomcat8-openshift:1.2* builder image
> # ASSERT: *websocket-chat* application is imported into your workspace
> # ASSERT: server adapter *jboss-webserver31-tomcat* is created
> # ASSERT: In OpenShift explorer, below the service jboss-webserver31-tomcat*, you have the running pod (build is finished, pod running)
> # EXEC: start the server adapter
> # ASSERT: RSync is executed and the output is visible in the "Console"
> Result:
> If you look closely at the output you see that the project is synced to the pod in a folder called *websocket-chat.jar*
> !console-output-1.png!
> Expected result:
> I should be able to set the output folder to anything I want. Ex. we have a customer that wants the application war to be synced up into a folder *ROOT* (without the extension *.war*).
> Currently, to achieve this I have to do the following:
> # EXEC: create the following xml snippet (notice the *outputName* property for the module)
> and make sure it reads as follows:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <deployment>
> <local>
> <module id="org.eclipse.jst.jee.server:websocket-chat">
> <property key="tempLocation" value="" />
> <property key="location" value="" />
> <property key="outputName" value="ROOT" />
> </module>
> </local>
> </deployment>
> {code}
> # EXEC: html-encode, join it into a single line and copy it (into the clipboard)
> # EXEC: open the properties for the server adapter and hit "Switch Location"
> !switch-location.png!
> # ASSERT: in my workspace, a new project *Servers* is created. It contains the configuration for my server adapter.
> !server-adapter-configuration.png!
> # EXEC: open the file with the *XML Editor*
> # EXEC: in your *XML Editor*: go to the end of the line *<server auto-publish-setting="2"* and insert your html-encoded xml as a value to the attribute *org.jboss.ide.eclipse.as.core.util.deploymentPreferenceKey="*
> {code}
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <server auto-publish-setting="2" auto-publish-time="2" hostname="jboss-webserver31-tomcat-test.192.168.64.76.nip.io" id="test@jboss-webserver31-tomcat" id-set="true" name="jboss-webserver31-tomcat (Service) at OpenShift 3 (192.168.64.76)" org.jboss.ide.eclipse.as.core.server.IGNORE_LAUNCH_COMMANDS="true" org.jboss.ide.eclipse.as.core.server.deployDirectoryType="custom" org.jboss.ide.eclipse.as.core.server.serverMode="openshift3" org.jboss.ide.eclipse.as.core.server.webPort="80" org.jboss.ide.eclipse.as.core.server.webPortAutoDetect="false" org.jboss.ide.eclipse.as.core.server.zipDeploymentsPreference="true" org.jboss.tools.openshift.Connection="https://developer@192.168.64.76:8443" org.jboss.tools.openshift.DeployProject="websocket-chat" org.jboss.tools.openshift.PodPath="/opt/webserver/webapps" org.jboss.tools.openshift.SERVER_START_ON_CREATION="false" org.jboss.tools.openshift.Service="test@jboss-webserver31-tomcat" org.jboss.tools.openshift.SourcePath="${workspace_loc:/websocket-chat}" port="80" runtime-id="test@jboss-webserver31-tomcat" server-type="org.jboss.tools.openshift.server.type" server-type-id="org.jboss.tools.openshift.server.type" start-timeout="450" stop-timeout="450" timestamp="2" org.jboss.ide.eclipse.as.core.util.deploymentPreferenceKey="<?xml version="1.0" encoding="UTF-8"?> <deployment> <local> <module id="org.eclipse.jst.jee.server:websocket-chat"> <property key="tempLocation" value="" /> <property key="location" value="" /> <property key="outputName" value="ROOT" /> </module> </local> </deployment>">
> <list key="modules" value0="websocket-chat::org.eclipse.jst.jee.server:websocket-chat::jst.web::3.0"/>
> </server>
> {code}
> # EXEC: Save the editor and restart the server
> Result:
> Syncing now happens into a folder *ROOT*
> !console-output-2.png!
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (JBIDE-26737) Set up new Jenkins on PSI with use of JCasC
by Ondrej Dockal (Jira)
[ https://issues.jboss.org/browse/JBIDE-26737?page=com.atlassian.jira.plugi... ]
Ondrej Dockal updated JBIDE-26737:
----------------------------------
Description:
Prepare new jenkins instance to accommodate JCasC configuration for CodeReady Studio team needs.
* -Request instance on PSI-
* Change settings to our repo
* Defined basic workflow
was:
Prepare new jenkins instance to accommodate JCasC configuration for CodeReady Studio team needs.
* Request instance on PSI
* Change settings to our repo
* Defined basic workflow
> Set up new Jenkins on PSI with use of JCasC
> -------------------------------------------
>
> Key: JBIDE-26737
> URL: https://issues.jboss.org/browse/JBIDE-26737
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: qa
> Affects Versions: 4.13.x
> Reporter: Ondrej Dockal
> Assignee: Ondrej Dockal
> Priority: Critical
> Labels: jenkins, quality
> Fix For: 4.13.x
>
>
> Prepare new jenkins instance to accommodate JCasC configuration for CodeReady Studio team needs.
> * -Request instance on PSI-
> * Change settings to our repo
> * Defined basic workflow
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (JBIDE-26441) The server was shutdown forcefully. All processes were terminated.
by Josef Kopriva (Jira)
[ https://issues.jboss.org/browse/JBIDE-26441?page=com.atlassian.jira.plugi... ]
Josef Kopriva closed JBIDE-26441.
---------------------------------
Closing, no steps to reproduce.
> The server was shutdown forcefully. All processes were terminated.
> ------------------------------------------------------------------
>
> Key: JBIDE-26441
> URL: https://issues.jboss.org/browse/JBIDE-26441
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: eclipse.buildId=11.3.0.GA-v20180413-0714-B2352
> java.version=1.8.0_181
> jboss data virtualization server 6.3
> Reporter: Rakesh Jain
> Assignee: Rob Stryker
> Priority: Blocker
> Fix For: 4.12.0.Final
>
>
> eclipse.buildId=11.3.0.GA-v20180413-0714-B2352
> java.version=1.8.0_181
> java.vendor=Oracle Corporation
> BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
> Framework arguments: -product com.jboss.devstudio.core.product
> Command-line arguments: -os win32 -ws win32 -arch x86_64 -product com.jboss.devstudio.core.product
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months