[JBoss JIRA] (JBIDE-25611) Server adapter: timeouts when starting into "Debug" on OpenShift Online
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25611?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-25611 at 1/25/18 3:32 PM:
-------------------------------------------------------------------
[~jcantrill] any idea why only on OpenShift Online (all others work: cdk 3.2, 3.3, open.paas.redhat.com, origin 3.7.1) wont expose the debug port for a pod that is set to debugging (via env variables: dev_mode + debug_port -> launch params show that node was launched for debugging)? see [comment-13523309|https://issues.jboss.org/browse/JBIDE-25611?focusedComme...])
was (Author: adietish):
[~jcantrill] any idea why only on OpenShift Online (all others work: cdk 3.2, 3.3, open.paas.redhat.com, origin 3.7.1) wont expose the debug port for a pod that is set to debugging (via env variables: dev_mode + debug_port -> launch params show that node was launched for debugging)?
> Server adapter: timeouts when starting into "Debug" on OpenShift Online
> -----------------------------------------------------------------------
>
> Key: JBIDE-25611
> URL: https://issues.jboss.org/browse/JBIDE-25611
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.5.2.Final
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.5.3.AM1
>
> Attachments: error-waiting-for-new-pod.png, image-2018-01-24-18-58-29-159.png, image-2018-01-25-10-49-09-369.png, pod-ports-cdk.png, pod-ports-online.png, port-missing.png
>
>
> # ASSERT: have an account on OpenShift Online
> # EXEC: create a new application via template nodejs-mongo-persistent
> # EXEC: have the project imported into the workspace and the server adapter for it created
> # ASSERT: you have a new server adapter for your app in state [stopped]
> # EXEC: start the adapter into "Debug"
> Result:
> The adapter takes a lot of time to start but wont succeed eventually. You get the following error dialog:
> !error-waiting-for-new-pod.png!
> In the Eclipse log you'll find the following:
> {code}
> org.eclipse.core.runtime.CoreException: Failed to detect new deployed Pod for nodejs-mongo-persistent
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.waitFor(OpenShiftDebugMode.java:403)
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.waitForNewPod(OpenShiftDebugMode.java:395)
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.getPod(OpenShiftDebugMode.java:226)
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.execute(OpenShiftDebugMode.java:170)
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftLaunchController.launch(OpenShiftLaunchController.java:100)
> at org.jboss.ide.eclipse.as.wtp.core.server.launch.ControllableServerLaunchConfiguration.launch(ControllableServerLaunchConfiguration.java:52)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
> at org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3566)
> at org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3502)
> at org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:377)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (JBIDE-25611) Server adapter: timeouts when starting into "Debug" on OpenShift Online
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25611?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-25611:
------------------------------------------
[~jcantrill] any idea why only on OpenShift Online (all others work: cdk 3.2, 3.3, open.paas.redhat.com, origin 3.7.1) wont expose the debug port for a pod that is set to debugging (via env variables: dev_mode + debug_port -> launch params show that node was launched for debugging)?
> Server adapter: timeouts when starting into "Debug" on OpenShift Online
> -----------------------------------------------------------------------
>
> Key: JBIDE-25611
> URL: https://issues.jboss.org/browse/JBIDE-25611
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.5.2.Final
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.5.3.AM1
>
> Attachments: error-waiting-for-new-pod.png, image-2018-01-24-18-58-29-159.png, image-2018-01-25-10-49-09-369.png, pod-ports-cdk.png, pod-ports-online.png, port-missing.png
>
>
> # ASSERT: have an account on OpenShift Online
> # EXEC: create a new application via template nodejs-mongo-persistent
> # EXEC: have the project imported into the workspace and the server adapter for it created
> # ASSERT: you have a new server adapter for your app in state [stopped]
> # EXEC: start the adapter into "Debug"
> Result:
> The adapter takes a lot of time to start but wont succeed eventually. You get the following error dialog:
> !error-waiting-for-new-pod.png!
> In the Eclipse log you'll find the following:
> {code}
> org.eclipse.core.runtime.CoreException: Failed to detect new deployed Pod for nodejs-mongo-persistent
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.waitFor(OpenShiftDebugMode.java:403)
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.waitForNewPod(OpenShiftDebugMode.java:395)
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.getPod(OpenShiftDebugMode.java:226)
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.execute(OpenShiftDebugMode.java:170)
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftLaunchController.launch(OpenShiftLaunchController.java:100)
> at org.jboss.ide.eclipse.as.wtp.core.server.launch.ControllableServerLaunchConfiguration.launch(ControllableServerLaunchConfiguration.java:52)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
> at org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3566)
> at org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3502)
> at org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:377)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (JBIDE-25611) Server adapter: timeouts when starting into "Debug" on OpenShift Online
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25611?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-25611 at 1/25/18 1:01 PM:
-------------------------------------------------------------------
[~jeffmaury] the port should be exposed in the (new) pod (not the deployment config) once you set the dc in "debug" mode via the 2 env vars (dev_mode and debug_port).
!image-2018-01-25-10-49-09-369.png!
I now switched to CDK 3.3 (from 3.2) and it behaves fine for me, exposes the debug port once the dc is in "debug" mode.
To sum up the current situtation:
|| product || versions || Status ||
| cdk 3.2 | minishift v1.7.0+204ce19, CDK v3.2.0-1 | {color:green}OK{color} |
| cdk 3.3 | OpenShift Master: v3.7.14 Kubernetes
Master: v1.7.6+a08f5eeb62 | {color:green}OK{color} |
| OpenShift Online | OpenShift Master: v3.7.23 (online version 3.6.0.32.1)
Kubernetes Master: v1.7.6+a08f5eeb62 | {color:red}NOT OK{color} |
| open.pass.redhat.com | OpenShift Master: v3.6.173.0.83
Kubernetes Master: v1.6.1+5115d708d7 | {color:green}OK{color} |
| origin 3.7.1 | openshift v3.7.1+ab0f056
kubernetes v1.7.6+a08f5eeb62 | {color:green}OK{color}
was (Author: adietish):
[~jeffmaury] the port should be exposed in the (new) pod (not the deployment config) once you set the dc in "debug" mode via the 2 env vars (dev_mode and debug_port).
!image-2018-01-25-10-49-09-369.png!
I now switched to CDK 3.3 (from 3.2) and it behaves fine for me, exposes the debug port once the dc is in "debug" mode.
To sum up the current situtation:
|| product || versions || Status ||
| cdk 3.2 | minishift v1.7.0+204ce19, CDK v3.2.0-1 | {color:green}OK{color} |
| cdk 3.3 | OpenShift Master: v3.7.14 Kubernetes
Master: v1.7.6+a08f5eeb62 | {color:green}OK{color} |
| OpenShift Online | OpenShift Master: v3.7.23 (online version 3.6.0.32.1)
Kubernetes Master: v1.7.6+a08f5eeb62 | {color:red}NOT OK{color} |
| open.pass.redhat.com | OpenShift Master: v3.6.173.0.83
Kubernetes Master: v1.6.1+5115d708d7 | {color:green}OK{color} |
> Server adapter: timeouts when starting into "Debug" on OpenShift Online
> -----------------------------------------------------------------------
>
> Key: JBIDE-25611
> URL: https://issues.jboss.org/browse/JBIDE-25611
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.5.2.Final
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.5.3.AM1
>
> Attachments: error-waiting-for-new-pod.png, image-2018-01-24-18-58-29-159.png, image-2018-01-25-10-49-09-369.png, pod-ports-cdk.png, pod-ports-online.png, port-missing.png
>
>
> # ASSERT: have an account on OpenShift Online
> # EXEC: create a new application via template nodejs-mongo-persistent
> # EXEC: have the project imported into the workspace and the server adapter for it created
> # ASSERT: you have a new server adapter for your app in state [stopped]
> # EXEC: start the adapter into "Debug"
> Result:
> The adapter takes a lot of time to start but wont succeed eventually. You get the following error dialog:
> !error-waiting-for-new-pod.png!
> In the Eclipse log you'll find the following:
> {code}
> org.eclipse.core.runtime.CoreException: Failed to detect new deployed Pod for nodejs-mongo-persistent
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.waitFor(OpenShiftDebugMode.java:403)
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.waitForNewPod(OpenShiftDebugMode.java:395)
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.getPod(OpenShiftDebugMode.java:226)
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.execute(OpenShiftDebugMode.java:170)
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftLaunchController.launch(OpenShiftLaunchController.java:100)
> at org.jboss.ide.eclipse.as.wtp.core.server.launch.ControllableServerLaunchConfiguration.launch(ControllableServerLaunchConfiguration.java:52)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
> at org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3566)
> at org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3502)
> at org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:377)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (JBIDE-25611) Server adapter: timeouts when starting into "Debug" on OpenShift Online
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25611?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-25611 at 1/25/18 1:01 PM:
-------------------------------------------------------------------
[~jeffmaury] the port should be exposed in the (new) pod (not the deployment config) once you set the dc in "debug" mode via the 2 env vars (dev_mode and debug_port).
!image-2018-01-25-10-49-09-369.png!
I now switched to CDK 3.3 (from 3.2) and it behaves fine for me, exposes the debug port once the dc is in "debug" mode.
To sum up the current situtation:
|| product || versions || Status ||
| cdk 3.2 | minishift v1.7.0+204ce19, CDK v3.2.0-1 | {color:green}OK{color} |
| cdk 3.3 | OpenShift Master: v3.7.14 Kubernetes
Master: v1.7.6+a08f5eeb62 | {color:green}OK{color} |
| OpenShift Online | OpenShift Master: v3.7.23 (online version 3.6.0.32.1)
Kubernetes Master: v1.7.6+a08f5eeb62 | {color:red}NOT OK{color} |
| open.pass.redhat.com | OpenShift Master: v3.6.173.0.83
Kubernetes Master: v1.6.1+5115d708d7 | {color:green}OK{color} |
| origin 3.7.1 | openshift v3.7.1+ab0f056
kubernetes v1.7.6+a08f5eeb62 | {color:green}OK{color} |
was (Author: adietish):
[~jeffmaury] the port should be exposed in the (new) pod (not the deployment config) once you set the dc in "debug" mode via the 2 env vars (dev_mode and debug_port).
!image-2018-01-25-10-49-09-369.png!
I now switched to CDK 3.3 (from 3.2) and it behaves fine for me, exposes the debug port once the dc is in "debug" mode.
To sum up the current situtation:
|| product || versions || Status ||
| cdk 3.2 | minishift v1.7.0+204ce19, CDK v3.2.0-1 | {color:green}OK{color} |
| cdk 3.3 | OpenShift Master: v3.7.14 Kubernetes
Master: v1.7.6+a08f5eeb62 | {color:green}OK{color} |
| OpenShift Online | OpenShift Master: v3.7.23 (online version 3.6.0.32.1)
Kubernetes Master: v1.7.6+a08f5eeb62 | {color:red}NOT OK{color} |
| open.pass.redhat.com | OpenShift Master: v3.6.173.0.83
Kubernetes Master: v1.6.1+5115d708d7 | {color:green}OK{color} |
| origin 3.7.1 | openshift v3.7.1+ab0f056
kubernetes v1.7.6+a08f5eeb62 | {color:green}OK{color}
> Server adapter: timeouts when starting into "Debug" on OpenShift Online
> -----------------------------------------------------------------------
>
> Key: JBIDE-25611
> URL: https://issues.jboss.org/browse/JBIDE-25611
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.5.2.Final
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.5.3.AM1
>
> Attachments: error-waiting-for-new-pod.png, image-2018-01-24-18-58-29-159.png, image-2018-01-25-10-49-09-369.png, pod-ports-cdk.png, pod-ports-online.png, port-missing.png
>
>
> # ASSERT: have an account on OpenShift Online
> # EXEC: create a new application via template nodejs-mongo-persistent
> # EXEC: have the project imported into the workspace and the server adapter for it created
> # ASSERT: you have a new server adapter for your app in state [stopped]
> # EXEC: start the adapter into "Debug"
> Result:
> The adapter takes a lot of time to start but wont succeed eventually. You get the following error dialog:
> !error-waiting-for-new-pod.png!
> In the Eclipse log you'll find the following:
> {code}
> org.eclipse.core.runtime.CoreException: Failed to detect new deployed Pod for nodejs-mongo-persistent
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.waitFor(OpenShiftDebugMode.java:403)
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.waitForNewPod(OpenShiftDebugMode.java:395)
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.getPod(OpenShiftDebugMode.java:226)
> at org.jboss.tools.openshift.internal.core.server.debug.OpenShiftDebugMode.execute(OpenShiftDebugMode.java:170)
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftLaunchController.launch(OpenShiftLaunchController.java:100)
> at org.jboss.ide.eclipse.as.wtp.core.server.launch.ControllableServerLaunchConfiguration.launch(ControllableServerLaunchConfiguration.java:52)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
> at org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3566)
> at org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3502)
> at org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:377)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (JBIDE-25665) It is not possible to update from 4.5.1. to 4.5.2.Final using Check for Update
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25665?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-25665 at 1/25/18 9:59 AM:
-------------------------------------------------------------
I suspect this might be the fix you're looking for:
https://github.com/jbosstools/jbosstools-webservices/pull/285
https://imgflip.com/i/23c1k3
Steps to verify:
a) install JBT 4.5.1.Final
b) build the above PR locally
c) add file://path/to/jbosstools-webservices/site/target/repository/ to list of available software sites
d) Check for Updates
e) success?
was (Author: nickboldt):
I suspect this might be the fix you're looking for:
https://github.com/jbosstools/jbosstools-webservices/pull/285
https://imgflip.com/i/23c1k3
> It is not possible to update from 4.5.1. to 4.5.2.Final using Check for Update
> ------------------------------------------------------------------------------
>
> Key: JBIDE-25665
> URL: https://issues.jboss.org/browse/JBIDE-25665
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.5.2.Final
> Reporter: Lukáš Valach
> Assignee: Nick Boldt
> Fix For: 4.5.3.AM1
>
> Attachments: CheckForUpdates.png
>
>
> It is not possible to update to 4.5.2.Final using "Check for Update". Check for Update is not able to find any remedy for this conflict:
> {code}
> Cannot complete the install because of a conflicting dependency.
> Software being installed: JBoss JAX-RS Tools 2.0.0.v20180105-1426 (org.jboss.tools.ws.jaxrs.feature.feature.group 2.0.0.v20180105-1426)
> Software currently installed: JBoss WebServices Tools 1.9.101.v20170822-1704 (org.jboss.tools.ws.feature.feature.group 1.9.101.v20170822-1704)
> Only one of the following can be installed at once:
> JBoss WebServices Tools 2.0.0.v20180105-1426 (org.jboss.tools.ws.ui 2.0.0.v20180105-1426)
> JBoss WebServices Tools 1.9.101.v20170822-1704 (org.jboss.tools.ws.ui 1.9.101.v20170822-1704)
> Cannot satisfy dependency:
> From: JBoss WebServices Tools 1.9.101.v20170822-1704 (org.jboss.tools.ws.feature.feature.group 1.9.101.v20170822-1704)
> To: org.jboss.tools.ws.ui [1.9.101.v20170822-1704]
> Cannot satisfy dependency:
> From: JBoss JAX-RS Tools 2.0.0.v20180105-1426 (org.jboss.tools.ws.jaxrs.feature.feature.group 2.0.0.v20180105-1426)
> To: org.jboss.tools.ws.ui [2.0.0.v20180105-1426]
> {code}
> !CheckForUpdates.png|thumbnail!
> It is maybe caused by separation of SOAP from jbosstools-webservices (JBIDE-24880).
> This process is routinely tested and the test passed on Friday/Monday, but unfortunately I made a mistake. I installed JBT 4.5.1 from Eclipse Marketplace, then I added staging update site and executed Check for Update which passed without any problems. But I didn't realize that JBT 4.5.1 added stable update site for 4.5.1, which was used together with 4.5.2 update site, so it was able to resolve that conflict. So I apologize for this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (JBIDE-25665) It is not possible to update from 4.5.1. to 4.5.2.Final using Check for Update
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25665?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-25665:
------------------------------------
I suspect this might be the fix you're looking for:
https://github.com/jbosstools/jbosstools-webservices/pull/285
https://imgflip.com/i/23c1k3
> It is not possible to update from 4.5.1. to 4.5.2.Final using Check for Update
> ------------------------------------------------------------------------------
>
> Key: JBIDE-25665
> URL: https://issues.jboss.org/browse/JBIDE-25665
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.5.2.Final
> Reporter: Lukáš Valach
> Assignee: Nick Boldt
> Fix For: 4.5.3.AM1
>
> Attachments: CheckForUpdates.png
>
>
> It is not possible to update to 4.5.2.Final using "Check for Update". Check for Update is not able to find any remedy for this conflict:
> {code}
> Cannot complete the install because of a conflicting dependency.
> Software being installed: JBoss JAX-RS Tools 2.0.0.v20180105-1426 (org.jboss.tools.ws.jaxrs.feature.feature.group 2.0.0.v20180105-1426)
> Software currently installed: JBoss WebServices Tools 1.9.101.v20170822-1704 (org.jboss.tools.ws.feature.feature.group 1.9.101.v20170822-1704)
> Only one of the following can be installed at once:
> JBoss WebServices Tools 2.0.0.v20180105-1426 (org.jboss.tools.ws.ui 2.0.0.v20180105-1426)
> JBoss WebServices Tools 1.9.101.v20170822-1704 (org.jboss.tools.ws.ui 1.9.101.v20170822-1704)
> Cannot satisfy dependency:
> From: JBoss WebServices Tools 1.9.101.v20170822-1704 (org.jboss.tools.ws.feature.feature.group 1.9.101.v20170822-1704)
> To: org.jboss.tools.ws.ui [1.9.101.v20170822-1704]
> Cannot satisfy dependency:
> From: JBoss JAX-RS Tools 2.0.0.v20180105-1426 (org.jboss.tools.ws.jaxrs.feature.feature.group 2.0.0.v20180105-1426)
> To: org.jboss.tools.ws.ui [2.0.0.v20180105-1426]
> {code}
> !CheckForUpdates.png|thumbnail!
> It is maybe caused by separation of SOAP from jbosstools-webservices (JBIDE-24880).
> This process is routinely tested and the test passed on Friday/Monday, but unfortunately I made a mistake. I installed JBT 4.5.1 from Eclipse Marketplace, then I added staging update site and executed Check for Update which passed without any problems. But I didn't realize that JBT 4.5.1 added stable update site for 4.5.1, which was used together with 4.5.2 update site, so it was able to resolve that conflict. So I apologize for this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (JBIDE-25665) It is not possible to update from 4.5.1. to 4.5.2.Final using Check for Update
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25665?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-25665:
------------------------------------
I suppose we could adjust the new soap feature so that it knows it's an update for the old (no longer existant) feature, which WOULD allow check for updates to find an update path.
We've done that in the past for other cases of namespace refactoring -- I guess no one thought we'd need this when we agreed to refactor jbosstools-webservices (JBIDE-24880).
So... this is something we could try to fix for 4.5.3.x but I don't consider it a blocker for 4.5.2 as Install New Software *will* present the remediation that will solve this, even if Check for Updates won't.
> It is not possible to update from 4.5.1. to 4.5.2.Final using Check for Update
> ------------------------------------------------------------------------------
>
> Key: JBIDE-25665
> URL: https://issues.jboss.org/browse/JBIDE-25665
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.5.2.Final
> Reporter: Lukáš Valach
> Assignee: Nick Boldt
> Fix For: 4.5.3.AM1
>
> Attachments: CheckForUpdates.png
>
>
> It is not possible to update to 4.5.2.Final using "Check for Update". Check for Update is not able to find any remedy for this conflict:
> {code}
> Cannot complete the install because of a conflicting dependency.
> Software being installed: JBoss JAX-RS Tools 2.0.0.v20180105-1426 (org.jboss.tools.ws.jaxrs.feature.feature.group 2.0.0.v20180105-1426)
> Software currently installed: JBoss WebServices Tools 1.9.101.v20170822-1704 (org.jboss.tools.ws.feature.feature.group 1.9.101.v20170822-1704)
> Only one of the following can be installed at once:
> JBoss WebServices Tools 2.0.0.v20180105-1426 (org.jboss.tools.ws.ui 2.0.0.v20180105-1426)
> JBoss WebServices Tools 1.9.101.v20170822-1704 (org.jboss.tools.ws.ui 1.9.101.v20170822-1704)
> Cannot satisfy dependency:
> From: JBoss WebServices Tools 1.9.101.v20170822-1704 (org.jboss.tools.ws.feature.feature.group 1.9.101.v20170822-1704)
> To: org.jboss.tools.ws.ui [1.9.101.v20170822-1704]
> Cannot satisfy dependency:
> From: JBoss JAX-RS Tools 2.0.0.v20180105-1426 (org.jboss.tools.ws.jaxrs.feature.feature.group 2.0.0.v20180105-1426)
> To: org.jboss.tools.ws.ui [2.0.0.v20180105-1426]
> {code}
> !CheckForUpdates.png|thumbnail!
> It is maybe caused by separation of SOAP from jbosstools-webservices (JBIDE-24880).
> This process is routinely tested and the test passed on Friday/Monday, but unfortunately I made a mistake. I installed JBT 4.5.1 from Eclipse Marketplace, then I added staging update site and executed Check for Update which passed without any problems. But I didn't realize that JBT 4.5.1 added stable update site for 4.5.1, which was used together with 4.5.2 update site, so it was able to resolve that conflict. So I apologize for this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months