[JBoss JIRA] (JBDS-4065) DevStudio 1.1 Installer unfriendly when 1.0 present
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBDS-4065?page=com.atlassian.jira.plugin.... ]
Len DiMaggio commented on JBDS-4065:
------------------------------------
For DevStudio upgrades, we have historically enabled customers to re-use old workspaces. Are we agreeing to now stop support for that? Thx!
> 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
>
> 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
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23093) use consistent variables across all jenkins jobs for streams, TP versions, etc.
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23093?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-23093:
-------------------------------
Description:
We have a number of inconsistencies between jobs / pom.xml:
* TARGET_PLATFORM_CENTRAL_MAX vs. JBTCENTRALTARGET_VERSION
* TARGET_PLATFORM_VERSION vs. TARGET_PLATFORM_VERSION_MIN
* TARGET_PLATFORM_VERSION_MAXIMUM vs. TARGET_PLATFORM_VERSION_MAX
* stream_jbt vs. jbosstools_site_stream
Should standardize these.
was:
We have a number of inconsistencies between jobs:
* TARGET_PLATFORM_CENTRAL_MAX vs. JBTCENTRALTARGET_VERSION
* TARGET_PLATFORM_VERSION vs. TARGET_PLATFORM_VERSION_MIN
* stream_jbt vs. jbosstools_site_stream
* ...
> use consistent variables across all jenkins jobs for streams, TP versions, etc.
> -------------------------------------------------------------------------------
>
> Key: JBIDE-23093
> URL: https://issues.jboss.org/browse/JBIDE-23093
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.4.1.Final
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.2.AM2
>
>
> We have a number of inconsistencies between jobs / pom.xml:
> * TARGET_PLATFORM_CENTRAL_MAX vs. JBTCENTRALTARGET_VERSION
> * TARGET_PLATFORM_VERSION vs. TARGET_PLATFORM_VERSION_MIN
> * TARGET_PLATFORM_VERSION_MAXIMUM vs. TARGET_PLATFORM_VERSION_MAX
> * stream_jbt vs. jbosstools_site_stream
> Should standardize these.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23023) Valiadation of credentials does not work for some runtimes in Download Runtime Wizard
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23023?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-23023:
-------------------------------
Fix Version/s: 4.4.2.AM2
> Valiadation of credentials does not work for some runtimes in Download Runtime Wizard
> -------------------------------------------------------------------------------------
>
> Key: JBIDE-23023
> URL: https://issues.jboss.org/browse/JBIDE-23023
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.4.1.AM3
> Environment: Devstudio 10.1.0.AM3-v20160819-0530-B5800
> Reporter: Radim Hopp
> Assignee: Radim Hopp
> Priority: Critical
> Fix For: 4.4.2.AM2
>
>
> Valiadation of username and password in DownloadRuntimesWizard does not work for JBoss EAP 6.0 to 6.2 and JBoss Portal Platform 6.1.0. It does work for JBoss EAP 6.3 to 7.0, JBoss FSW 6.0, JBoss Data Virtualization 6.1.0 and 6.2.0.
> For the mentioned runtimes, where it does not work it lets you accept license, but fails on download.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-22543) Different errors when closing Central right after it was opened
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22543?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-22543:
-------------------------------
Fix Version/s: 4.4.2.AM2
(was: 4.4.x)
> Different errors when closing Central right after it was opened
> ---------------------------------------------------------------
>
> Key: JBIDE-22543
> URL: https://issues.jboss.org/browse/JBIDE-22543
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Affects Versions: 4.4.0.Final
> Environment: Devstudio 10.0.0.GA-v20160603-1025-B5510
> Reporter: Radim Hopp
> Assignee: Jeff MAURY
> Priority: Minor
> Fix For: 4.4.2.AM2
>
>
> Opening and closing central gives me two different errors:
> {noformat}
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.eclipse.mylyn.internal.discovery.core.util.P2TransportService.download(P2TransportService.java:86)
> at org.eclipse.mylyn.internal.discovery.core.util.WebUtil.download(WebUtil.java:157)
> at org.eclipse.mylyn.internal.discovery.core.util.WebUtil.download(WebUtil.java:66)
> at org.jboss.tools.discovery.core.internal.connectors.xpl.RemoteExternalBundleDiscoveryStrategy$DownloadBundleJob.call(RemoteExternalBundleDiscoveryStrategy.java:223)
> at org.jboss.tools.discovery.core.internal.connectors.xpl.RemoteExternalBundleDiscoveryStrategy$DownloadBundleJob.call(RemoteExternalBundleDiscoveryStrategy.java:1)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor92.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.eclipse.mylyn.internal.discovery.core.util.P2TransportService.download(P2TransportService.java:84)
> ... 8 more
> Caused by: org.eclipse.core.runtime.OperationCanceledException
> at org.eclipse.core.internal.jobs.JobManager.join(JobManager.java:999)
> at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.readInto(FileReader.java:360)
> at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.download(RepositoryTransport.java:101)
> at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.download(RepositoryTransport.java:156)
> ... 12 more
> {noformat}
> and
> {noformat:title=Failed to get connectors from RemoteProxyWizardDiscoveryStrategy}
> org.eclipse.core.runtime.CoreException: IO failure: cannot load discovery directory
> at org.jboss.tools.discovery.core.internal.connectors.xpl.RemoteExternalBundleDiscoveryStrategy.loadRegistry(RemoteExternalBundleDiscoveryStrategy.java:111)
> at org.jboss.tools.discovery.core.internal.connectors.xpl.ExternalBundleDiscoveryStrategy.performDiscovery(ExternalBundleDiscoveryStrategy.java:117)
> at org.jboss.tools.discovery.core.internal.connectors.ChainedDiscoveryStrategy.performDiscovery(ChainedDiscoveryStrategy.java:68)
> at org.eclipse.mylyn.internal.discovery.core.model.ConnectorDiscovery.performDiscovery(ConnectorDiscovery.java:114)
> at org.jboss.tools.central.internal.discovery.wizards.ProxyWizardManager.loadWizards(ProxyWizardManager.java:107)
> at org.jboss.tools.central.internal.discovery.wizards.ProxyWizardUpdateJob.run(ProxyWizardUpdateJob.java:47)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.io.IOException: Cancelled by user
> at org.eclipse.equinox.internal.p2.transport.ecf.FileReader$1.checkException(FileReader.java:337)
> at org.eclipse.equinox.internal.p2.transport.ecf.FileReader$1.close(FileReader.java:287)
> at org.eclipse.mylyn.internal.discovery.core.util.WebUtil.readResource(WebUtil.java:101)
> at org.jboss.tools.discovery.core.internal.connectors.xpl.RemoteExternalBundleDiscoveryStrategy.loadRegistry(RemoteExternalBundleDiscoveryStrategy.java:91)
> ... 6 more
> Caused by: org.eclipse.core.runtime.OperationCanceledException: Cancelled by user
> at org.eclipse.equinox.internal.p2.transport.ecf.FileReader$1.checkException(FileReader.java:334)
> ... 9 more
> Caused by: org.eclipse.ecf.filetransfer.UserCancelledException: Cancelled by user
> at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.newUserCancelledException(AbstractRetrieveFileTransfer.java:442)
> at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.setDoneCanceled(AbstractRetrieveFileTransfer.java:472)
> at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.cancel(HttpClientRetrieveFileTransfer.java:228)
> at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.handleTransferEvent(FileReader.java:213)
> at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.fireTransferReceiveDataEvent(AbstractRetrieveFileTransfer.java:390)
> at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.fireTransferReceiveDataEvent(HttpClientRetrieveFileTransfer.java:1116)
> at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.handleReceivedData(AbstractRetrieveFileTransfer.java:294)
> at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer$1.performFileTransfer(AbstractRetrieveFileTransfer.java:179)
> at org.eclipse.ecf.filetransfer.FileTransferJob.run(FileTransferJob.java:74)
> ... 1 more
> {noformat}
> They do not appear every time, but pretty often.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-21065) Server host name address should not be defaulted during server adapter creation
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21065?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-21065:
-------------------------------
Fix Version/s: 4.4.2.AM2
(was: 4.4.x)
> Server host name address should not be defaulted during server adapter creation
> -------------------------------------------------------------------------------
>
> Key: JBIDE-21065
> URL: https://issues.jboss.org/browse/JBIDE-21065
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server, upstream
> Affects Versions: 4.3.0.Final
> Reporter: Xavier Coulon
> Assignee: Rob Stryker
> Fix For: 4.4.2.AM2
>
>
> I've noticed that when I create a server adapter and I give it an IP address as the hostname, the hostname remains the default value, ie, {{localhost}}.
> This is annoying in the case where I want to connect to a VM running on my own host (eg, a VM running Docker). In this particular case, I set the hostname at something like {{192.168.99.100}} but it is reverted as {{localhost}} which gives {{127.0.0.1}} as the primary IP address. As a consequence, the server adapter fails to connect to the server since it uses the wrong IP address.
> Note that the host name can be changed for good in the Server Configuration Editor _after_ its creation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-22598) Support runtime detection for manual CDK install
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22598?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-22598:
-------------------------------
Fix Version/s: 4.4.2.AM2
(was: 4.4.x)
> Support runtime detection for manual CDK install
> ------------------------------------------------
>
> Key: JBIDE-22598
> URL: https://issues.jboss.org/browse/JBIDE-22598
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdk, runtime-detection
> Affects Versions: 4.4.0.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.2.AM2
>
>
> Right now with CDK 2.1 when you have a manual cdk install (i.e. using cdk.zip and then adding the vagrant box yourself), there will be no .cdk marker, so Runtime Detection will not work.
> The only case where Runtime Detection will work is when you use the (as of now Windows-only) suite installer. At that point Runtime Detection will do its thing silently without you noticing.
> The way I see it there are two options:
> a) Create and upstream issue with CDK and ask them to include a basic .cdk in their zip
> b) Make the runtime detection work without .cdk
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-19506) Connection wizard, Connection: should have unit tests
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19506?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19506:
-------------------------------
Fix Version/s: 4.4.2.AM2
(was: 4.4.x)
> Connection wizard, Connection: should have unit tests
> ------------------------------------------------------
>
> Key: JBIDE-19506
> URL: https://issues.jboss.org/browse/JBIDE-19506
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: openshift_v3, tests
> Fix For: 4.4.2.AM2
>
> Original Estimate: 2 days
> Time Spent: 3 days
> Remaining Estimate: 3 days
>
> In the new implementation of the connection wizard, that allows v2 and v3 connections (JBIDE-19096) we have rather complex behaviour that we should assert via unit tests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23150) Properties: wont show OpenShift properties if stacked in same container as OpenShift explorer
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23150?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-23150:
-------------------------------
Fix Version/s: 4.4.2.AM2
(was: 4.4.x)
> Properties: wont show OpenShift properties if stacked in same container as OpenShift explorer
> ---------------------------------------------------------------------------------------------
>
> Key: JBIDE-23150
> URL: https://issues.jboss.org/browse/JBIDE-23150
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.Final
> Reporter: Andre Dietisheim
> Assignee: Dmitrii Bocharov
> Fix For: 4.4.2.AM2
>
> Attachments: openshift-explorer-and-properties-both-stacked.png, properties-empty.png
>
>
> If you have the OpenShift explorer and the Properties view both stacked in the same view like it is shown in the following screenshot:
> !openshift-explorer-and-properties-both-stacked.png!
> and you start up Eclipse with the Properties view visible (not OpenShift explorer) you wont be able to ever see any property of any OpenShift resource. The properties view always stays empty.
> steps to reproduce:
> # ASSERT: have Properties view and OpenShift explorer (stacked) in the same visual container
> # ASSERT: make sure any view (but OpenShift explorer) is visible when you start Eclipse
> # EXEC: make Properties view visible
> # EXEC: make OpenShift explorer visible. Select an entry
> # EXEC: switch back to Properties view
> Result:
> Properties view stays empty. You can switch back and forth, you wont get any content in the properties view.
> !properties-empty.png!
> Only moving Properties view to a different (visual) container helps.
> the steps simply show a reliable way to reproduce it. I think there are more cases where this happens. Root cause could be in platform, not sure though.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months