June 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-22578) Publishing sometimes recursively deletes parent to deploy directory

by Daniel Atallah (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22578?page=com.atlassian.jira.plugi... ] Daniel Atallah commented on JBIDE-22578: ---------------------------------------- I think we've identified what's unique/wrong with our configuration leading to this problem. In the {{.settings/org.eclipse.wst.common.component}} for a WAR Project, we found the following block: {noformat} <project-modules id="moduleCoreId" project-version="2.0"> <wb-module deploy-name="MobileWeb"> ... <dependent-module deploy-path="../" handle="module:/resource/core/core"> <dependency-type>uses</dependency-type> </dependent-module> </wb-module> </project-modules> {noformat} The above is the correct syntax for the deploy-path for a resource module project, but not for the WAR itself, which should be: {noformat} <project-modules id="moduleCoreId" project-version="2.0"> <wb-module deploy-name="MobileWeb"> ... <dependent-module deploy-path="/WEB-INF/lib" handle="module:/resource/core/core"> <dependency-type>uses</dependency-type> </dependent-module> </wb-module> </project-modules> {noformat} It isn't clear to me why {{$WORKSPACEROOT\deploy\..}} ends up being deleted as a result of this, I would expect it to try to delete {{$WORKSPACEROOT\deploy\MobileWeb\..\core.jar}} instead. I also don't have any clues as to why this happens only intermittently. > 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: Blocker > Fix For: 4.4.1.S116 > > Attachments: jboss_deployment.jpg, 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 (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3884) Define the version of EAP that we embed with next major version of devstudio

by Len DiMaggio (JIRA)

[ https://issues.jboss.org/browse/JBDS-3884?page=com.atlassian.jira.plugin.... ] Len DiMaggio commented on JBDS-3884: ------------------------------------ We will want to only link to versions of EAP with which the installed version of DevStudio is known (and verified to) work successfully. ;-) > Define the version of EAP that we embed with next major version of devstudio > ---------------------------------------------------------------------------- > > Key: JBDS-3884 > URL: https://issues.jboss.org/browse/JBDS-3884 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Task > Components: runtime > Affects Versions: 10.0.0.GA > Reporter: Len DiMaggio > Assignee: Todd Mancini > Fix For: 10.x > > > EAP 7.0 will be in devstudio 10.0.0.GA, but future releases may change the way packaging occurs. See linked Trello cards for Big Questions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22594) Deploy Docker Image wizard: password/token for registry is not prefilled even after choosing a connection

by Dmitry Bocharov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22594?page=com.atlassian.jira.plugi... ] Dmitry Bocharov commented on JBIDE-22594: ----------------------------------------- [~adietish], ok, thank you, it is more clear now. But look [here|https://github.com/jbosstools/jbosstools-openshift/pull/1114#issueco...]. Fred and Slava decided that it is ok to skip the connection page and go to deploy page right away. [Here is the according change|https://github.com/jbosstools/jbosstools-openshift/pull/1114/files...] > Deploy Docker Image wizard: password/token for registry is not prefilled even after choosing a connection > --------------------------------------------------------------------------------------------------------- > > Key: JBIDE-22594 > URL: https://issues.jboss.org/browse/JBIDE-22594 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.0.Final > Reporter: Andre Dietisheim > Assignee: Dmitry Bocharov > Labels: connection_wizard, deploy_docker_wizard, openshift_v3 > Fix For: 4.4.1.S116 > > Attachments: out-2.ogv > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22362) Server Adapter: Static changes done to nodejs application are not visible

by Ilya Buziuk (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22362?page=com.atlassian.jira.plugi... ] Ilya Buziuk reassigned JBIDE-22362: ----------------------------------- Assignee: Ilya Buziuk (was: Marián Labuda) > Server Adapter: Static changes done to nodejs application are not visible > ------------------------------------------------------------------------- > > Key: JBIDE-22362 > URL: https://issues.jboss.org/browse/JBIDE-22362 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.0.Alpha2 > Reporter: Marián Labuda > Assignee: Ilya Buziuk > Priority: Critical > Labels: openshift_v3, server_adapter > Fix For: 4.4.1.S116 > > > I am having an OpenShift application based either on nodejs-example or nodejs-mongodb-example template. Once application is up and running I create a new server adapter and perform changes in index.html. These changes are static and should be (?) immediately visible on OpenShift server, but they are not. I have checked whether changes were published, but rsync in console shows expected output also changes done manually on the server side to index.html are not visible in browser (even when cache overwritten is triggered - so there is no caching problem in browser). This seems to be upstream issues, but requires investigating. > So far I have tried it on CDK OpenShift. It would be nice to test it on other OpenShift instances, also on templates using different base docker image. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ERT-204) Docker Machine lookup does not work on Windows machines [EBZ#494305]

by Trevor Trevor (JIRA)

[ https://issues.jboss.org/browse/ERT-204?page=com.atlassian.jira.plugin.sy... ] Trevor Trevor edited comment on ERT-204 at 6/22/16 1:30 PM: ------------------------------------------------------------ I am getting the same exception, but was able to workaround it by just copying the docker-machine.exe into the same directory and removing the .exe extension. This does appear to only be something wrong with the configuration page, as I was able to see my images and containers from the docker explorer without following this step. It is quite annoying however, because you are unable to navigate away from this configuration page if it does not detect docker-machine. When you attempt to, it will bring up a dialog window letting you know that the changes could not be accepted. This forces you to cancel out of the preferences page. Edit: I just not realized that eclipse neon was mentioned, but I am running eclipse mars.2 was (Author: wrestang): I am getting the same exception, but was able to workaround it by just copying the docker-machine.exe into the same directory and removing the .exe extension. This does appear to only be something wrong with the configuration page, as I was able to see my images and containers from the docker explorer without following this step. It is quite annoying however, because you are unable to navigate away from this configuration page if it does not detect docker-machine. When you attempt to, it will bring up a dialog window letting you know that the changes could not be accepted. This forces you to cancel out of the preferences page. > Docker Machine lookup does not work on Windows machines [EBZ#494305] > -------------------------------------------------------------------- > > Key: ERT-204 > URL: https://issues.jboss.org/browse/ERT-204 > Project: Eclipse Release Train > Issue Type: Task > Components: Linux Tools > Reporter: Friendly Jira Robot > Assignee: Xavier Coulon > Labels: 5.0.0, Docker, bzira > Fix For: Neon (4.6) > > > When creating Docker connection, the docker-machine mechanism does not work on Window as it seems to find docker-machine and not docker-machine.exe -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ERT-204) Docker Machine lookup does not work on Windows machines [EBZ#494305]

by Trevor Trevor (JIRA)

[ https://issues.jboss.org/browse/ERT-204?page=com.atlassian.jira.plugin.sy... ] Trevor Trevor commented on ERT-204: ----------------------------------- I am getting the same exception, but was able to workaround it by just copying the docker-machine.exe into the same directory and removing the .exe extension. This does appear to only be something wrong with the configuration page, as I was able to see my images and containers from the docker explorer without following this step. It is quite annoying however, because you are unable to navigate away from this configuration page if it does not detect docker-machine. When you attempt to, it will bring up a dialog window letting you know that the changes could not be accepted. This forces you to cancel out of the preferences page. > Docker Machine lookup does not work on Windows machines [EBZ#494305] > -------------------------------------------------------------------- > > Key: ERT-204 > URL: https://issues.jboss.org/browse/ERT-204 > Project: Eclipse Release Train > Issue Type: Task > Components: Linux Tools > Reporter: Friendly Jira Robot > Assignee: Xavier Coulon > Labels: 5.0.0, Docker, bzira > Fix For: Neon (4.6) > > > When creating Docker connection, the docker-machine mechanism does not work on Window as it seems to find docker-machine and not docker-machine.exe -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22633) jbosstools-multiple.target has multiple incompatible IUs

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22633?page=com.atlassian.jira.plugi... ] Paul Leacu reassigned JBIDE-22633: ---------------------------------- Assignee: Nick Boldt > jbosstools-multiple.target has multiple incompatible IUs > -------------------------------------------------------- > > Key: JBIDE-22633 > URL: https://issues.jboss.org/browse/JBIDE-22633 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: target-platform > Reporter: Paul Leacu > Assignee: Nick Boldt > Priority: Critical > Fix For: 4.4.1.S116 > > > Please correct the jbosstools-multiple.target to avoid the duplication of the IU as this is causing build failures in both SwitchYard and Fuse Tooling (development). > https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/... > https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/... > org.eclipse.egit.ui.smartimport is defined twice with two different versions: > {code} > [ERROR] Resolution failed: > [ERROR] Software being installed: org.eclipse.egit.ui.smartimport 4.4.0.201606011500-rc2 > [ERROR] Software being installed: org.eclipse.egit.ui.smartimport 4.4.0.201606070830-r > [ERROR] Only one of the following can be installed at once: [org.eclipse.egit.ui.smartimport 4.4.0.201606070830-r, org.eclipse.egit.ui.smartimport 4.4.0.201606011500-rc2] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22269) Work with WildFly/EAP to generate unit tests on server installation layout

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22269?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-22269: -------------------------------- Fix Version/s: 4.4.1.S116 (was: 4.4.x) > Work with WildFly/EAP to generate unit tests on server installation layout > -------------------------------------------------------------------------- > > Key: JBIDE-22269 > URL: https://issues.jboss.org/browse/JBIDE-22269 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: server > Affects Versions: 4.4.0.Alpha1 > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.4.1.S116 > > > A task to track work on making sure changes to EAP don't inadvertently break tools when changing directory structure or important keys we read. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19081) Use simpler Surefire include/exclude pattern in parent pom

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19081?page=com.atlassian.jira.plugi... ] Alexey Kazakov reassigned JBIDE-19081: -------------------------------------- Assignee: Nick Boldt (was: Max Rydahl Andersen) > Use simpler Surefire include/exclude pattern in parent pom > ---------------------------------------------------------- > > Key: JBIDE-19081 > URL: https://issues.jboss.org/browse/JBIDE-19081 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Minor > Fix For: 4.4.x > > > 1. In JBDS9, use these new default patterns for Surefire to define which test classes to run/exclude: > {code} > include = *Test*, *Test, *TestCase > exclude = *Abstract* > {code} > 2. If that causes test failures because running incorrectly named > abstract stuff, they can refactor, add their own root pom overrides, use > a TestSuite, or use @Ignore in test classes. > 3. If the count of tests run suddenly DROPS because the pattern isn't > running the correct # of tests, they can add their own root pom > overrides, or use a TestSuite. > Ref: http://lists.jboss.org/pipermail/jbosstools-dev/2015-January/009688.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22634) fix buildflow jobs to correctly represent interdependencies of jbosstools-* projects

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22634?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22634: ------------------------------- Description: Some jobs fail when upstream deps have not been published: * aerogear depends browsersim * browsersim depends jst * vpe depends jst * arquillian depends javaee * central depends javaee * javaee depends vpe So need to retool the buildflow jobs (and the force-push ones too) to correctly align with these dep chains. was: Some jobs fail when upstream deps have not been published: * aerogear depends on browsersim * browsersim depends on jst * vpe depends on jst So need to retool the buildflow jobs (and the force-push ones too) to correctly align with these dep chains. > fix buildflow jobs to correctly represent interdependencies of jbosstools-* projects > ------------------------------------------------------------------------------------ > > Key: JBIDE-22634 > URL: https://issues.jboss.org/browse/JBIDE-22634 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.S116 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.S116 > > > Some jobs fail when upstream deps have not been published: > * aerogear depends browsersim > * browsersim depends jst > * vpe depends jst > * arquillian depends javaee > * central depends javaee > * javaee depends vpe > So need to retool the buildflow jobs (and the force-push ones too) to correctly align with these dep chains. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues June 2016