[JBoss JIRA] (JBIDE-23023) Valiadation of credentials does not work for some runtimes in Download Runtime Wizard
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23023?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-23023.
---------------------------------
Resolution: Done
It seems this is fixed on the live server now. So it's out of staging and live (adn so much easier to test)
> 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] (JBDS-4065) DevStudio 1.1 Installer unfriendly when 1.0 present
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-4065?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov commented on JBDS-4065:
--------------------------------------
To be clear. If you changed the location of the vagrant file then it's expected that you need to fix it in your server adapter.
But the following should work:
1. Vagarnt binaries should be available anyway. Even if you reinstalled them. If they are available in CLI they should be available in tooling automatically.
2. New devsuite installation should create a new ready-to-go CDK server adapter even if there are some existing ones in the old workspace.
> 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-23276) Blank refactoring menu
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23276?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-23276:
-----------------------------------
Fix Version/s: 4.5.x
> Blank refactoring menu
> ----------------------
>
> Key: JBIDE-23276
> URL: https://issues.jboss.org/browse/JBIDE-23276
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: batch
> Affects Versions: 4.4.2.AM1
> Reporter: Lukáš Valach
> Priority: Minor
> Fix For: 4.5.x
>
> Attachments: BatchRenameManualTest.zip, JobXmlRefactoring_1.png, JobXmlRefactoring_2.png
>
>
> When I click some reference in job.xml file, there is the "Refactor" item in the context menu. Refactoring item seems to be available [^JobXmlRefactoring_1.png], but when I hover the Refactoring item the blank menu appears and Refactoring item become unavailable/disabled [^JobXmlRefactoring_2.png].
> Refactoring item should be unavailable immediately, or there should be at least one item in Refactoring menu (the Rename maybe?).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23274) Rename of batch artefact should affect batch.xml file
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23274?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-23274:
-----------------------------------
Fix Version/s: 4.5.x
> Rename of batch artefact should affect batch.xml file
> -----------------------------------------------------
>
> Key: JBIDE-23274
> URL: https://issues.jboss.org/browse/JBIDE-23274
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: batch
> Affects Versions: 4.4.2.AM1
> Reporter: Lukáš Valach
> Fix For: 4.5.x
>
> Attachments: BatchRenameManualTest.zip
>
>
> There are three ways how to refer batch artefact in job.xml file.
> * Using @Name annotation
> * Using fully qualified class name
> * Using batch.xml
> I noticed that the class name is not changed in batch.xml file during refactoring and the job.xml file become invalid for this reason.
> There is a way how to avoid this problem. User can check the "Update fully qualified names in non-Java text files" option in Rename window, but this solution is not intuitive/is not user friendly I think.
> In another case, when I don't use batch.xml and use the name comming from @Named annotation. The artefact is renamed in job.xml file even if the "Update fully qualified names in non-Java text files" option aren't selected. Non-Java text file (job.xml) is updated automatically in this case.
> There is attached project that you can use to reproduce this problem.
> [^BatchRenameManualTest.zip]. Just try to rename Writer class.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23274) Rename of batch artefact should affect batch.xml file
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23274?page=com.atlassian.jira.plugi... ]
Alexey Kazakov reassigned JBIDE-23274:
--------------------------------------
Assignee: Alexey Kazakov
> Rename of batch artefact should affect batch.xml file
> -----------------------------------------------------
>
> Key: JBIDE-23274
> URL: https://issues.jboss.org/browse/JBIDE-23274
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: batch
> Affects Versions: 4.4.2.AM1
> Reporter: Lukáš Valach
> Assignee: Alexey Kazakov
> Fix For: 4.5.x
>
> Attachments: BatchRenameManualTest.zip
>
>
> There are three ways how to refer batch artefact in job.xml file.
> * Using @Name annotation
> * Using fully qualified class name
> * Using batch.xml
> I noticed that the class name is not changed in batch.xml file during refactoring and the job.xml file become invalid for this reason.
> There is a way how to avoid this problem. User can check the "Update fully qualified names in non-Java text files" option in Rename window, but this solution is not intuitive/is not user friendly I think.
> In another case, when I don't use batch.xml and use the name comming from @Named annotation. The artefact is renamed in job.xml file even if the "Update fully qualified names in non-Java text files" option aren't selected. Non-Java text file (job.xml) is updated automatically in this case.
> There is attached project that you can use to reproduce this problem.
> [^BatchRenameManualTest.zip]. Just try to rename Writer class.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23275) Rename doesn't change fully qualified name in job.xml file
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23275?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-23275:
-----------------------------------
Fix Version/s: 4.5.x
> Rename doesn't change fully qualified name in job.xml file
> ----------------------------------------------------------
>
> Key: JBIDE-23275
> URL: https://issues.jboss.org/browse/JBIDE-23275
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: batch
> Affects Versions: 4.4.2.AM1
> Environment: Fedora 24
> Reporter: Lukáš Valach
> Fix For: 4.5.x
>
> Attachments: BatchRenameManualTest.zip
>
>
> Refactoring doesn't modify job.xml when I renaming class which is referred in job.xml using the fully qualified name.
> For example, when I have batchlet class
> {code:java}
> package test;
> public class BatchletWithProperty extends AbstractBatchlet {
> ...
> }
> {code}
> ...and job.xml
> {code:xml}
> <job ...>
> <step id="step1">
> <batchlet ref="test.BatchletWithProperty"> <!-- linked using the fully qualified name -->
> ...
> </batchlet>
> </step>
> ...
> </job>
> {code}
> ...then, when I try to rename test.BatchletWithProperty the refactoring doesn't change fully qualified name in job.xml.
> Renaming works properly when I refer to class using name coming from @Named annotation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23277) Update arquillian bot integration tests - to resolve intermittent timing issue
by Len DiMaggio (JIRA)
Len DiMaggio created JBIDE-23277:
------------------------------------
Summary: Update arquillian bot integration tests - to resolve intermittent timing issue
Key: JBIDE-23277
URL: https://issues.jboss.org/browse/JBIDE-23277
Project: Tools (JBoss Tools)
Issue Type: Task
Components: qa
Affects Versions: 4.4.2.AM1
Reporter: Len DiMaggio
Priority: Minor
Recent updates to tests have exposed another timing issue that had been masked - need to increase the timeout for Central to load as this is causing intermittent timeouts and test failures:
org.jboss.reddeer.common.exception.WaitTimeoutExpiredException: Timeout after: 10 s.: Waiting for Central to load
at org.jboss.reddeer.common.wait.AbstractWait.timeoutExceeded(AbstractWait.java:183)
at org.jboss.reddeer.common.wait.AbstractWait.wait(AbstractWait.java:136)
at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:101)
at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:71)
at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:56)
at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:44)
at org.jboss.reddeer.common.wait.WaitUntil.<init>(WaitUntil.java:35)
at org.jboss.tools.arquillian.ui.bot.test.cruiserView.BasicArquilliaCruiserTest.setup(BasicArquilliaCruiserTest.java:48)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23277) Update arquillian bot integration tests - to resolve intermittent timing issue
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23277?page=com.atlassian.jira.plugi... ]
Len DiMaggio reassigned JBIDE-23277:
------------------------------------
Assignee: Len DiMaggio
> Update arquillian bot integration tests - to resolve intermittent timing issue
> ------------------------------------------------------------------------------
>
> Key: JBIDE-23277
> URL: https://issues.jboss.org/browse/JBIDE-23277
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: qa
> Affects Versions: 4.4.2.AM1
> Reporter: Len DiMaggio
> Assignee: Len DiMaggio
> Priority: Minor
>
> Recent updates to tests have exposed another timing issue that had been masked - need to increase the timeout for Central to load as this is causing intermittent timeouts and test failures:
> org.jboss.reddeer.common.exception.WaitTimeoutExpiredException: Timeout after: 10 s.: Waiting for Central to load
> at org.jboss.reddeer.common.wait.AbstractWait.timeoutExceeded(AbstractWait.java:183)
> at org.jboss.reddeer.common.wait.AbstractWait.wait(AbstractWait.java:136)
> at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:101)
> at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:71)
> at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:56)
> at org.jboss.reddeer.common.wait.AbstractWait.<init>(AbstractWait.java:44)
> at org.jboss.reddeer.common.wait.WaitUntil.<init>(WaitUntil.java:35)
> at org.jboss.tools.arquillian.ui.bot.test.cruiserView.BasicArquilliaCruiserTest.setup(BasicArquilliaCruiserTest.java:48)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months