[JBoss JIRA] (JBDS-4298) DevSuite Installer alway downloads DevStudio even there is valid installer.jar in cache
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-4298?page=com.atlassian.jira.plugin.... ]
Denis Golovin reassigned JBDS-4298:
-----------------------------------
Assignee: Denis Golovin
> DevSuite Installer alway downloads DevStudio even there is valid installer.jar in cache
> ---------------------------------------------------------------------------------------
>
> Key: JBDS-4298
> URL: https://issues.jboss.org/browse/JBDS-4298
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 10.3.0.GA
> Environment: Windows 10
> Reporter: Todd Mancini
> Assignee: Denis Golovin
> Fix For: 10.4.0.AM1
>
>
> Installer tries to reuse files downloaded during previous install. It checks for previously downloaded files in %TEMP% directory and verifies the SHA256. If checksum matches the one included into configuration Installer skip download and use file form %TEMP% folder.
> This works fine for all components except DevStudio.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBDS-4298) DevSuite Installer alway downloads DevStudio even there is valid installer.jar in cache
by Denis Golovin (JIRA)
Denis Golovin created JBDS-4298:
-----------------------------------
Summary: DevSuite Installer alway downloads DevStudio even there is valid installer.jar in cache
Key: JBDS-4298
URL: https://issues.jboss.org/browse/JBDS-4298
Project: Red Hat JBoss Developer Studio (devstudio)
Issue Type: Bug
Components: platform-installer
Affects Versions: 10.3.0.GA
Environment: Windows 10
Reporter: Denis Golovin
Installer tries to reuse files downloaded during previous install. It checks for previously downloaded files in %TEMP% directory and verifies the SHA256. If checksum matches the one included into configuration Installer skip download and use file form %TEMP% folder.
This works fine for all components except DevStudio.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBDS-4298) DevSuite Installer alway downloads DevStudio even there is valid installer.jar in cache
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-4298?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-4298:
--------------------------------
Fix Version/s: 10.4.0.AM1
> DevSuite Installer alway downloads DevStudio even there is valid installer.jar in cache
> ---------------------------------------------------------------------------------------
>
> Key: JBDS-4298
> URL: https://issues.jboss.org/browse/JBDS-4298
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 10.3.0.GA
> Environment: Windows 10
> Reporter: Denis Golovin
> Fix For: 10.4.0.AM1
>
>
> Installer tries to reuse files downloaded during previous install. It checks for previously downloaded files in %TEMP% directory and verifies the SHA256. If checksum matches the one included into configuration Installer skip download and use file form %TEMP% folder.
> This works fine for all components except DevStudio.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBDS-4065) DevSuite 1.1 Installer unfriendly when 1.0 present
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-4065?page=com.atlassian.jira.plugin.... ]
Denis Golovin reassigned JBDS-4065:
-----------------------------------
Assignee: Denis Golovin (was: Rob Stryker)
> DevSuite 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: Denis Golovin
> Fix For: 10.4.0.AM2
>
>
> 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
[JBoss JIRA] (JBDS-4065) DevSuite 1.1 Installer unfriendly when 1.0 present
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-4065?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-4065:
--------------------------------
Summary: DevSuite 1.1 Installer unfriendly when 1.0 present (was: DevStudio 1.1 Installer unfriendly when 1.0 present)
> DevSuite 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.AM2
>
>
> 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
[JBoss JIRA] (JBIDE-24047) Error dialog displayed after cancel when starting cdk3 server adapter
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24047?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-24047.
---------------------------------
Resolution: Rejected
Unfortunately, this can't be fixed.
When you right-click a server, and select 'Run..." or "Debug...", WTP starts a job called waiting for server to start.
Logic flows to our launch config. If our launchConfig.launch(etc) returns WITHOUT setting server to 'starting', then WTP will display an error dialog that the server failed to start.
If we set it to 'starting' and then set it to 'stopped', WTP will show an error dialog that the server failed to start.
If we throw a CoreException, the CoreException will be shown in an error dialog.
Basically, once a user clicks "Start" or "Debug", an error dialog will be shown 100% of the time no matter what ;) We have no options here.
Since it's launch configuration based, we really can't tell the difference between an abort or a fail without providing custom WTP interfaces that our launches must implement. Even then, WTP Servertools is notoriously strict about what API they are willing to consider, and this falls far outside the bounds of what they'd see as acceptable. (Trust me... 10 years experience with them ;))
Sorry, but an error dialog is going up no matter what ;)
> Error dialog displayed after cancel when starting cdk3 server adapter
> ---------------------------------------------------------------------
>
> Key: JBIDE-24047
> URL: https://issues.jboss.org/browse/JBIDE-24047
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.4.AM1
> Reporter: Jeff MAURY
> Assignee: Rob Stryker
> Labels: cdk
> Fix For: 4.4.4.AM2
>
> Attachments: screenshot-1.png
>
>
> When starting the CDK3 server adapter, a dialog is displayed for credentials. If cancel is selected, start is aborted but an error dialog is then displayed
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBIDE-18912) Custom deploy dir with remote server using filesystem operations does not work
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18912?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-18912:
--------------------------------
Fix Version/s: 4.5.0.AM2
(was: 4.4.4.AM1)
> Custom deploy dir with remote server using filesystem operations does not work
> ------------------------------------------------------------------------------
>
> Key: JBIDE-18912
> URL: https://issues.jboss.org/browse/JBIDE-18912
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.1.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Labels: help_wanted
> Fix For: 4.5.0.AM2
>
>
> This is a follow up of JBIDE-17180 and JBIDE-13445 which added the option to add a custom deployment directory if your remote server is using filesystem operations (for management api it's not relevant since the deployment happens directly, no directory is used).
> Unfortunately it does not work. It seems I haven't really tried it when reviewing those other JIRAs because there were other obstacles.
> I tried this several times and still could not get it to work.
> Perhaps it might be worth to try and get this in the final 4.2.1.Final build?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBIDE-23677) write maven enforcer test to ensure we set correct version of foundation.core (based on parent pom version)
by Mat Booth (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23677?page=com.atlassian.jira.plugi... ]
Mat Booth edited comment on JBIDE-23677 at 3/10/17 11:24 AM:
-------------------------------------------------------------
This seems to be related to the "push to staging" sanity checks failing, for example:
https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo...
{code}
04:22:18 + echo 'In foundation.core, want 4.4.4.AM1, got 4.4.3.AM1 from org.jboss.tools.foundation.core_1.3.4.AM1-v20170309-1126-B65.jar'
04:22:18 + egrep 'foundation.core|4.4.4.AM1'
04:22:18 In foundation.core, want 4.4.4.AM1, got 4.4.3.AM1 from org.jboss.tools.foundation.core_1.3.4.AM1-v20170309-1126-B65.jar
04:22:18 + [[ 4.4.4.AM1 != 4.4.3.AM1 ]]
{code}
>From my local experiments, changing to the parent pom rather than the root pom as suggested in [~nickboldt]'s patch above ought to fix it, but I don't know the implications of doing so. I've left it for now, but this should be looked at for AM2
was (Author: mat.booth):
This seems to cause some "push to staging" sanity check to fail, for example:
https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo...
{code}
04:22:18 + echo 'In foundation.core, want 4.4.4.AM1, got 4.4.3.AM1 from org.jboss.tools.foundation.core_1.3.4.AM1-v20170309-1126-B65.jar'
04:22:18 + egrep 'foundation.core|4.4.4.AM1'
04:22:18 In foundation.core, want 4.4.4.AM1, got 4.4.3.AM1 from org.jboss.tools.foundation.core_1.3.4.AM1-v20170309-1126-B65.jar
04:22:18 + [[ 4.4.4.AM1 != 4.4.3.AM1 ]]
{code}
> write maven enforcer test to ensure we set correct version of foundation.core (based on parent pom version)
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-23677
> URL: https://issues.jboss.org/browse/JBIDE-23677
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, foundation
> Affects Versions: 4.4.3.AM1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.4.AM2, 4.5.0.AM1
>
>
> Wrong version of foundation.core detected. Should be 4.4.3, not 4.4.2.
> https://github.com/jbosstools/jbosstools-base/blob/master/foundation/plug...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBIDE-23677) write maven enforcer test to ensure we set correct version of foundation.core (based on parent pom version)
by Mat Booth (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23677?page=com.atlassian.jira.plugi... ]
Mat Booth edited comment on JBIDE-23677 at 3/10/17 11:14 AM:
-------------------------------------------------------------
This seems to cause some "push to staging" sanity check to fail, for example:
https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo...
{code}
04:22:18 + echo 'In foundation.core, want 4.4.4.AM1, got 4.4.3.AM1 from org.jboss.tools.foundation.core_1.3.4.AM1-v20170309-1126-B65.jar'
04:22:18 + egrep 'foundation.core|4.4.4.AM1'
04:22:18 In foundation.core, want 4.4.4.AM1, got 4.4.3.AM1 from org.jboss.tools.foundation.core_1.3.4.AM1-v20170309-1126-B65.jar
04:22:18 + [[ 4.4.4.AM1 != 4.4.3.AM1 ]]
{code}
was (Author: mat.booth):
Probably related, this seems to cause some "push to staging" sanity check to fail, for example:
https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo...
{code}
04:22:18 + echo 'In foundation.core, want 4.4.4.AM1, got 4.4.3.AM1 from org.jboss.tools.foundation.core_1.3.4.AM1-v20170309-1126-B65.jar'
04:22:18 + egrep 'foundation.core|4.4.4.AM1'
04:22:18 In foundation.core, want 4.4.4.AM1, got 4.4.3.AM1 from org.jboss.tools.foundation.core_1.3.4.AM1-v20170309-1126-B65.jar
04:22:18 + [[ 4.4.4.AM1 != 4.4.3.AM1 ]]
{code}
> write maven enforcer test to ensure we set correct version of foundation.core (based on parent pom version)
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-23677
> URL: https://issues.jboss.org/browse/JBIDE-23677
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, foundation
> Affects Versions: 4.4.3.AM1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.4.AM2, 4.5.0.AM1
>
>
> Wrong version of foundation.core detected. Should be 4.4.3, not 4.4.2.
> https://github.com/jbosstools/jbosstools-base/blob/master/foundation/plug...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years