[JBoss JIRA] (JBIDE-22278) Explorer: should be made visible when a new Connection is created
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22278?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-22278:
-----------------------------------------------
When CDK server is started, it can create both OpenShift connection, and Docker connection. I would suggest a message dialog reporting user what connections were created and giving options to open appropriate views and select new connections. User may prefer to stay with Servers view to see that adapter is successfully started.
> Explorer: should be made visible when a new Connection is created
> -----------------------------------------------------------------
>
> Key: JBIDE-22278
> URL: https://issues.jboss.org/browse/JBIDE-22278
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.0.Alpha1
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Labels: connection_wizard, explorer, openshift_v3
> Fix For: 4.4.0.Alpha2
>
>
> OpenShift Explorer should be made visible when a new Connection is created. This is particularly useful when the CDK Server creates an OpenShift Connection and the OpenShift Explorer is not visible.
> Could be done through a connection listener in the UI activator
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBDS-3864) Why is the platform installer installing pscp when Cygwin openssh scp is also installed?
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3864?page=com.atlassian.jira.plugin.... ]
Denis Golovin reassigned JBDS-3864:
-----------------------------------
Assignee: Denis Golovin
> Why is the platform installer installing pscp when Cygwin openssh scp is also installed?
> ----------------------------------------------------------------------------------------
>
> Key: JBDS-3864
> URL: https://issues.jboss.org/browse/JBDS-3864
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 9.1.0.Beta1
> Environment: Windows 7/64 bit.
> Reporter: Robert Terzi
> Assignee: Denis Golovin
> Priority: Optional
> Fix For: 10.0.0.Alpha1
>
>
> Why does the platform installer install putty's pscp.ese when it also installs Cygwin's openssh which includes scp?
> A while back vagrant-service-manager had a dependency on pscp.exe for copying certificates, but I believe that was eliminated a while back. (around the time of the rename from adbinfo to service-manager).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBDS-3864) Why is the platform installer installing pscp when Cygwin openssh scp is also installed?
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3864?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-3864:
--------------------------------
Fix Version/s: 10.0.0.Alpha1
> Why is the platform installer installing pscp when Cygwin openssh scp is also installed?
> ----------------------------------------------------------------------------------------
>
> Key: JBDS-3864
> URL: https://issues.jboss.org/browse/JBDS-3864
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 9.1.0.Beta1
> Environment: Windows 7/64 bit.
> Reporter: Robert Terzi
> Assignee: Denis Golovin
> Priority: Optional
> Fix For: 10.0.0.Alpha1
>
>
> Why does the platform installer install putty's pscp.ese when it also installs Cygwin's openssh which includes scp?
> A while back vagrant-service-manager had a dependency on pscp.exe for copying certificates, but I believe that was eliminated a while back. (around the time of the rename from adbinfo to service-manager).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-22289) Deploy Docker Wizard: Suggestion box of docker images is still visible on the next wizard page
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22289?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-22289:
-----------------------------------------------
[~fbricon], please take a look at the pull request.
> Deploy Docker Wizard: Suggestion box of docker images is still visible on the next wizard page
> -----------------------------------------------------------------------------------------------
>
> Key: JBIDE-22289
> URL: https://issues.jboss.org/browse/JBIDE-22289
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.0.Alpha1
> Environment: Fedora 22, GTK 3.
> Reporter: Marián Labuda
> Priority: Critical
> Labels: docker, openshift_v3
> Fix For: 4.4.0.Alpha2
>
>
> If I start typing name of image in Deploy Image to OpenShift wizard in the Image Name: text widget, suggestions are provided (autocomplete). If I select an image in this suggestion box by hitting Enter key, and then click by mouse on Next button, the next wizard page (Deployment Configuration and Scalability) shows this suggestion box again and on top, even it disappeared in previous wizard page.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBTIS-674) Deprecate 'SOA 5.x Compatibility' tooling
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBTIS-674?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBTIS-674:
-------------------------------------------
great - thanks for clarification. I never liked the separate connector for the runtimes detectors anyway :)
> Deprecate 'SOA 5.x Compatibility' tooling
> -----------------------------------------
>
> Key: JBTIS-674
> URL: https://issues.jboss.org/browse/JBTIS-674
> Project: JBoss Tools Integration Stack
> Issue Type: Feature Request
> Components: distribution
> Affects Versions: 9.0.0.GA
> Reporter: Paul Leacu
> Assignee: Paul Leacu
> Fix For: 4.3.0.Final, 9.0.0.GA
>
> Attachments: dep1.png, dep2.png, dep3.png, dep4.png, dep5.png
>
>
> The SOA 5.x Development tooling shall be marked as deprecated starting with 9.0.0.GA. It shall be removed at JBDSIS 10.0.0.GA (Neon). It consists of:
> org.guvnor.tools.feature
> org.jboss.tools.esb.feature
> org.jboss.tools.jbpm3.feature
> org.jboss.tools.jbpm.common.feature
> org.jboss.tools.jbpm.convert.feature
> The runtime detector features will not be deprecated:
> org.jboss.tools.runtime.drools.detector.feature
> org.jboss.tools.runtime.esb.detector.feature
> org.jboss.tools.runtime.jbpm.detector.feature
> FYI - [~apodhrad] [~bbrodt] [~maxandersen] [~ganandan-Redhat] [[~shelly.mcgowan]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBDS-3793) On Windows 10 (4K Display), installer dialogs are too small and cannot be resized
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3793?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-3793:
--------------------------------
Component/s: installer
(was: platform-installer)
> On Windows 10 (4K Display), installer dialogs are too small and cannot be resized
> ---------------------------------------------------------------------------------
>
> Key: JBDS-3793
> URL: https://issues.jboss.org/browse/JBDS-3793
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 9.1.0.CR1
> Environment: Version: 9.1.0.GA
> Build id: GA-v20160410-1849-B495
> Build date: 20160410-1849
> Windows 10
> 4K Display
> Reporter: Len DiMaggio
> Assignee: Denis Golovin
> Fix For: 10.x
>
> Attachments: installer.png
>
>
> See the attached screenshot - This issue has been raised before regarding the default size used for the JBDS IDE display - the issues that are specific to the JBDS installer is that the small sized dialogs obscure user-editable fields and and that the dialogs cannot be resized.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-13671) Replace build timestamp in qualifier by last-mod-timestamp from git
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13671:
------------------------------------
"If you use a different TP that affects the feature.xml resolution of what the 0.0.0 refers to does it not ? Thus it will behave differently since the content is actually different."
If you mean at install time, yes, but changing the version of the feature.jar won't change that behaviour. We already have this feature-not-a-bug which allows us to change the TP without updating JBDS, or change JBDS without changing the TP. They can move independently and p2 handles it.
If you mean at build time, no, because we don't package our TP artifacts into the features. We only *depend* on them; we do not *include* them. So the depend relationship continues to be to "the version available at build time" rather than "a specific version we've bundled up into this update site".
"why don't we delete the new duplicates ?"
Do you mean we would merge old plugins built a month ago (with the same timestamp/SHA) into a new CI build's update site, rather than using the freshly-rebuilt-from-the-same-SHA ones?
Because... Maven doesn't do that, and if we wanted to write our own "compare with old baseline and copy identically-timestamped IUs into the new CI site" we could. But given the fact that the same sources are used, surely the same output is produced, making the two jars bitwise nearly identical?
"how are you going to support not having a maintanence branch and product branch for developer studio"
When we create the first CR build for 4.4.0.Final / 10.0.0.GA), we would THEN cut a 4.4.x maintenance branch, in order to have a place to work on JBT 4.5 / DS 11.
But we won't need all the milestoneX (jbosstools-4.3.0.Beta1x, jbosstools-4.3.1.Beta1x, etc.) branches we currently use - all that extra churn and burn goes away in the interest of being more agile.
" if you installed month later you get the new one, but if you update you stay on the old build."
This is only true if the feature versions don't change while the plugin versions DO. But according to Tycho's doc, if a contained plugin changes, so too will the feature version change:
https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers#Feature_ve...
Oh, and note too:
{quote}Please note that if a feature directly includes bundles or features not part of the same code base but consumed via a target platform, the stability of a reproducible feature version qualifier also depends on the stability of the target platform in addition to the stability of the code base. If a rebuild occurs with a change in target platform, a different feature version qualifier might be generated.{quote}
So... TL;DR, Denis and I both like this idea.
Only major concern I've seen raised from Max (in March 2013) is "to get rid of snapshot dependencies first - maven deps, parent pom, target platform, maven plugins. Not tycho/p2-deps." I'm not convinced that any of the other concerns raised are real issues, only fears of the unknown.
So, to address the question of "maven deps, parent pom, target platform, maven plugins", I need more information. Max, can you clarify how changing the plugins/feature versions will impact our existing dependency on these upstream artifacts?
Further, if we released a parent pom 4.4.0.Final (not snapshot) and allowed no more parent pom changes for the rest of the 4.4.0.x development cycle, would that allay fears? If we do that, then the only way to release new TPs and have them used by devs/Jenkins would be ... commandline flags, which is non-ideal. Open to better ideas - I'm all out. :(
> Replace build timestamp in qualifier by last-mod-timestamp from git
> -------------------------------------------------------------------
>
> Key: JBIDE-13671
> URL: https://issues.jboss.org/browse/JBIDE-13671
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Priority: Optional
> Fix For: 4.4.0.Alpha2
>
> Attachments: jbide13671-before-and-after.png
>
>
> This needs to be added to master parent pom:
> {code}
> <plugin>
> <groupId>org.eclipse.tycho</groupId>
> <artifactId>tycho-packaging-plugin</artifactId>
> <version>${tycho.version}</version>
> <dependencies>
> <dependency>
> <groupId>org.eclipse.tycho.extras</groupId>
> <artifactId>tycho-buildtimestamp-jgit</artifactId>
> <version>${tycho-extras.version}</version>
> </dependency>
> </dependencies>
> <configuration>
> <strictBinIncludes>false</strictBinIncludes>
> <format>'v'yyyyMMdd-HHmm</format>
> <timestampProvider>jgit</timestampProvider>
> <jgit.ignore>
> </jgit.ignore>
> </configuration>
> </plugin>
> {code}
> Ref: http://pweclipse.blogspot.ch/2012_09_01_archive.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBDS-3863) Platform Installer Hung after CDK install failed, no way to cancel, no info on error.
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3863?page=com.atlassian.jira.plugin.... ]
Denis Golovin edited comment on JBDS-3863 at 5/2/16 1:41 PM:
-------------------------------------------------------------
This is most likely related to disk space shortage.
Installer should check for available disk space before continue with installation (see JBDS-3876) and translate error messages from cmd error out to UI.
was (Author: dgolovin):
This is most likely related to disk space shortage.
Installer should check for available disk space before continue with installation and translate error messages from cmd error out to UI.
> Platform Installer Hung after CDK install failed, no way to cancel, no info on error.
> --------------------------------------------------------------------------------------
>
> Key: JBDS-3863
> URL: https://issues.jboss.org/browse/JBDS-3863
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 9.1.0.Beta1
> Environment: Windows 7/64 bit.
> (Some components of previous manual CDK install on the system).
> Reporter: Robert Terzi
> Attachments: jbds-install-log-win7-error.txt
>
>
> Using the platform installer, CDK installation failed, progress shown as 99%. At this point the installer was hung.
> Note:
> * CDK install progress said Failed, with progress stuck at 99%.
> * There is no way to cancel out of the install.
> * There was no pop-up about error messages.
> * No indication of where to look for error messages/logs etc.was provided.
> * CDK was previously installed manually. However, the installer window didn't say a previous CDK installation was detected, but the log does show it deleted the previous cdkv2 box.
> From the log it looks like the box add command failed. This might have been due to disk space, but it's not clear/obvious from the log.
> Note: after killing the installer and trying the `vagrant box add` command copied from the log file manually in Cygwin bash the box add command succeeded. The test system had 5-15 GB of free space between the installation started.
> Full log attached, excerpt here.
> Tue, 26 Apr 2016 18:05:38 GMT-INFO: cdk - Move C:\Users\rct\AppData\Local\Temp\7zSC53C.tmp\rhel-vagrant-virtualbox.box to c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Move C:\Users\rct\AppData\Local\Temp\7zSC53C.tmp\rhel-vagrant-virtualbox.box to c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box SUCCESS
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Move C:\Users\rct\AppData\Local\Temp\7zSC53C.tmp\pscp.exe to c:\sw\rhjbds\cdk\bin\pscp.exe
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Move C:\Users\rct\AppData\Local\Temp\7zSC53C.tmp\pscp.exe to c:\sw\rhjbds\cdk\bin\pscp.exe SUCCESS
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Write C:\Users\rct\AppData\Local\Temp\set-pscp-path.ps1
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Write C:\Users\rct\AppData\Local\Temp\set-pscp-path.ps1 SUCCESS
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Write c:\sw\rhjbds\cdk\components\rhel\rhel-ose\.cdk
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Write c:\sw\rhjbds\cdk\components\rhel\rhel-ose\.cdk SUCCESS
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Execute powershell -ExecutionPolicy,ByPass,-File,C:\Users\rct\AppData\Local\Temp\set-pscp-path.ps1
> Tue, 26 Apr 2016 18:05:44 GMT-INFO: cdk - Execute powershell -ExecutionPolicy,ByPass,-File,C:\Users\rct\AppData\Local\Temp\set-pscp-path.ps1 SUCCESS
> Tue, 26 Apr 2016 18:05:44 GMT-INFO: cdk - postVagrantSetup called
> Tue, 26 Apr 2016 18:05:44 GMT-INFO: cdk - Execute command vagrant plugin install "c:\sw\rhjbds\cdk\plugins\vagrant-registration-1.2.1.gem"
> Tue, 26 Apr 2016 18:05:44 GMT-INFO: cdk - Execute options {
> "env": {
> "path": "C:\\HashiCorp\\Vagrant\\bin;C:\\Program Files\\Oracle\\VirtualBox\\;"
> }
> }
> Tue, 26 Apr 2016 18:05:55 GMT-INFO: cdk - Installing the 'c:\sw\rhjbds\cdk\plugins\vagrant-registration-1.2.1.gem' plugin. This can take a few minutes...
> Installed the plugin 'vagrant-registration (1.2.1)'!
> Tue, 26 Apr 2016 18:05:55 GMT-INFO: cdk - Execute vagrant plugin install "c:\sw\rhjbds\cdk\plugins\vagrant-registration-1.2.1.gem" SUCCESS
> Tue, 26 Apr 2016 18:05:55 GMT-INFO: cdk - Execute command vagrant box remove cdkv2 -f
> Tue, 26 Apr 2016 18:05:55 GMT-INFO: cdk - Execute options {
> "env": {
> "path": "C:\\HashiCorp\\Vagrant\\bin;C:\\Program Files\\Oracle\\VirtualBox\\;"
> }
> }
> Tue, 26 Apr 2016 18:06:02 GMT-INFO: cdk - Removing box 'cdkv2' (v0) with provider 'virtualbox'...
> Tue, 26 Apr 2016 18:06:02 GMT-INFO: cdk - Execute vagrant box remove cdkv2 -f SUCCESS
> Tue, 26 Apr 2016 18:06:02 GMT-INFO: cdk - Execute command vagrant box add --name cdkv2 "c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box"
> Tue, 26 Apr 2016 18:06:02 GMT-INFO: cdk - Execute options {
> "env": {
> "path": "C:\\HashiCorp\\Vagrant\\bin;C:\\Program Files\\Oracle\\VirtualBox\\;"
> }
> }
> Tue, 26 Apr 2016 18:06:10 GMT-ERROR: cdk - Error: Command failed: vagrant box add --name cdkv2 "c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box"
> The box failed to unpackage properly. Please verify that the box
> file you're trying to add is not corrupted and try again. The
> output from attempting to unpackage (if any):
> x box.ovf
> x Vagrantfile
> x vagrant-virtualbox-box.vmdk: Write failed
> x metadata.json
> bsdtar.EXE: Error exit delayed from previous errors.
> Tue, 26 Apr 2016 18:06:10 GMT-ERROR: cdk - The box failed to unpackage properly. Please verify that the box
> file you're trying to add is not corrupted and try again. The
> output from attempting to unpackage (if any):
> x box.ovf
> x Vagrantfile
> x vagrant-virtualbox-box.vmdk: Write failed
> x metadata.json
> bsdtar.EXE: Error exit delayed from previous errors.
> Tue, 26 Apr 2016 18:06:10 GMT-ERROR: cdk failed to install: Error: Command failed: vagrant box add --name cdkv2 "c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box"
> The box failed to unpackage properly. Please verify that the box
> file you're trying to add is not corrupted and try again. The
> output from attempting to unpackage (if any):
> x box.ovf
> x Vagrantfile
> x vagrant-virtualbox-box.vmdk: Write failed
> x metadata.json
> bsdtar.EXE: Error exit delayed from previous errors.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBDS-3876) Check available disk space for installation before continue
by Denis Golovin (JIRA)
Denis Golovin created JBDS-3876:
-----------------------------------
Summary: Check available disk space for installation before continue
Key: JBDS-3876
URL: https://issues.jboss.org/browse/JBDS-3876
Project: Red Hat Developer Studio (DevStudio)
Issue Type: Feature Request
Components: platform-installer
Affects Versions: 9.1.0.GA
Reporter: Denis Golovin
Assignee: Denis Golovin
Installer should check available disk space for target drive. vm image size is around 1G and it cause installer to fail when running CDK installtion, because vagrant box add command runs out of disk space (see linked issue for details).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months