[JBoss JIRA] (JBIDE-23819) Unable to determine oc 1.4.0 version
by Radim Hopp (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23819?page=com.atlassian.jira.plugi... ]
Radim Hopp edited comment on JBIDE-23819 at 2/2/17 2:58 AM:
------------------------------------------------------------
The "2" in enterprise binaries is rather weird... I tried 3.4.1.2 and 3.3.1.7 downloaded from access.redhat.com and I don't have it there.
{noformat}
$ ./oc-3.4.1.2-linux/oc version
oc v3.4.1.2
{noformat}
{noformat}
$ oc-3.3.1.7-linux/oc version
oc v3.3.1.7
{noformat}
(I'm on linux. Will try on mac & windows later today)
was (Author: rhopp):
The "2" in enterprise binaries is rather weird... I tried 3.4.1.2 and 3.3.1.7 downloaded from access.redhat.com and I don't have it there.
{noformat}
$ ./oc-3.4.1.2-linux/oc version
oc v3.4.1.2
{noformat}
{noformat}
$ oc-3.3.1.7-linux/oc version
oc v3.3.1.7
{noformat}
> Unable to determine oc 1.4.0 version
> ------------------------------------
>
> Key: JBIDE-23819
> URL: https://issues.jboss.org/browse/JBIDE-23819
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.3.AM2
> Environment: Devstudio 10.3.0.AM2, oc client v1.4.1 downloaded from https://github.com/openshift/origin/releases/tag/v1.4.1
> Reporter: Radim Hopp
> Assignee: Andre Dietisheim
> Priority: Critical
> Labels: oc_binary, openshift_v3
> Fix For: 4.4.3.Final
>
> Attachments: binary-not-oc.png, oc-14-not-recognized.png
>
>
> Selecting oc version 1.4.1 [1] in OpenShift 3 preferences dialog results in "Could not determine your OpenShift client version".
> [1] - https://github.com/openshift/origin/releases/tag/v1.4.1
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-23819) Unable to determine oc 1.4.0 version
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23819?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-23819 at 2/1/17 6:22 PM:
------------------------------------------------------------------
Furthermore, it is visible how the enterprise binary is not *"oc"* but *"oc 2"*. The current code cannot handle a binary that differs from *oc*.
!binary-not-oc.png!
was (Author: adietish):
Furthermore, it is visible how the enterprise binary is not *"oc"* but *"oc 2"*. The current code cannot handle a binary that differs from *oc*.
> Unable to determine oc 1.4.0 version
> ------------------------------------
>
> Key: JBIDE-23819
> URL: https://issues.jboss.org/browse/JBIDE-23819
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.3.AM2
> Environment: Devstudio 10.3.0.AM2, oc client v1.4.1 downloaded from https://github.com/openshift/origin/releases/tag/v1.4.1
> Reporter: Radim Hopp
> Assignee: Andre Dietisheim
> Priority: Critical
> Labels: oc_binary, openshift_v3
> Fix For: 4.4.3.Final
>
> Attachments: binary-not-oc.png, oc-14-not-recognized.png
>
>
> Selecting oc version 1.4.1 [1] in OpenShift 3 preferences dialog results in "Could not determine your OpenShift client version".
> [1] - https://github.com/openshift/origin/releases/tag/v1.4.1
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-23819) Unable to determine oc 1.4.0 version
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23819?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-23819:
------------------------------------------
The problem is that the regex, that's responsible for the detection of the oc version is bad.
In order to detect the version, "oc version" is run by the tooling.
I downloaded all oc binaries that exist currently and inspected the outputs.
Here they are
* oc binaries available from github:
{code}
oc v1.5.0-alpha.2+e4b43ee
oc v1.5.0-alpha.1+71d3fa9
oc v1.5.0-alpha.0+3b2bbe5
oc v1.4.1+3f9807a
oc v1.4.0+208f053
oc v1.4.0-rc1+b4e0954
oc v1.4.0-alpha.1+f189ede
oc v1.3.3
oc v1.3.2
oc v1.2.2
{code}
* oc (enterprise) binaries available from access.redhat.com:
{code}
oc 2 v3.4.1.2
oc 2 v3.4.0.40
oc 2 v3.4.0.39
oc 2 v3.3.1.7
oc 2 v3.3.1.5
oc 2 v3.3.1.4
oc 2 v3.3.1.3
{code}
> Unable to determine oc 1.4.0 version
> ------------------------------------
>
> Key: JBIDE-23819
> URL: https://issues.jboss.org/browse/JBIDE-23819
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.3.AM2
> Environment: Devstudio 10.3.0.AM2, oc client v1.4.1 downloaded from https://github.com/openshift/origin/releases/tag/v1.4.1
> Reporter: Radim Hopp
> Assignee: Andre Dietisheim
> Priority: Critical
> Labels: oc_binary, openshift_v3
> Fix For: 4.4.3.Final
>
> Attachments: oc-14-not-recognized.png
>
>
> Selecting oc version 1.4.1 [1] in OpenShift 3 preferences dialog results in "Could not determine your OpenShift client version".
> [1] - https://github.com/openshift/origin/releases/tag/v1.4.1
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBDS-4065) DevStudio 1.1 Installer unfriendly when 1.0 present
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBDS-4065?page=com.atlassian.jira.plugin.... ]
Rob Stryker updated JBDS-4065:
------------------------------
Fix Version/s: 10.4.0.AM1
> DevStudio 1.1 Installer unfriendly when 1.0 present
> ---------------------------------------------------
>
> Key: JBDS-4065
> URL: https://issues.jboss.org/browse/JBDS-4065
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: cdk, platform-installer
> Affects Versions: 10.1.0.GA
> Environment: Windows 10, DevSuite Installer 1.0 had been run
> Reporter: Rick Wagner
> Assignee: Rob Stryker
> Fix For: 10.4.0.AM1
>
>
> When running the DevSuite 1.1 installer, DevStudio is not connected to the installed CDK.
> Observations:
> - All components removed before installation, does not help. (VirtualBox and Vagrant using Add/Remove programs, everything else directory-deleted, Environment variables cleaned).
> - DevStudio says it can't start the Container Development Environment server. ('Failed to find Vagrant!' reads the error). If I open Launch Configuration, it lists the Main as "C:\HashiCorp\Vagrant\bin\vagrant.exe", which is not in the installation directory.
> - It was noted that DevStudio marked itself 'completed' before Vagrant was installed. How does DevStudio know where Vagrant is?
> - It's noted that DevStudio 'remembers' user settings (i.e. CDK registration user/password) from previous attempts. Where is this information kept? I must've missed something in cleanup.
> - Tried full suite installation, then deleting DevStudio, then re-installing. (Hoping DevStudio would then find Vagrant in the right location, because it followed Vagrant's installation.) Result: No Container Development Environment server is present in 'server' view.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-22625) Remote server with FS operations: Unable to retrieve a list of remote deployment scanners
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22625?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22625:
--------------------------------
Fix Version/s: 4.5.0.AM1
> Remote server with FS operations: Unable to retrieve a list of remote deployment scanners
> -----------------------------------------------------------------------------------------
>
> Key: JBIDE-22625
> URL: https://issues.jboss.org/browse/JBIDE-22625
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.4.0.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.5.0.AM1
>
>
> Previously I reported this as part of JBIDE-22605, but I think it deserves its own issue.
> When I setup a remote EAP 7 server with FS operations and then start it, I always get this in the error log:
> Unable to retrieve a list of remote deployment scanners for server Red Hat JBoss EAP 7.0
> Today, I also noticed this info message in the error view:
> org.eclipse.rse.core
> Saved passwords are not available for migration to secure storage. Deprecated authorization classes (org.eclipse.core.runtime.compatibility.auth) are not installed.
> I wonder if this is related? Do we require authentication to get the list of deployment scanners?
> BTW, org.eclipse.core.runtime.compatibility was removed in JBIDE-21382 and I suggested org.eclipse.core.runtime.compatibility.auth may be removed too - JBIDE-22602. But as of now it's still in the TP.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month