September 2018 - jbosstools-issues

[JBoss JIRA] (JBIDE-26380) pod log command does not work if oc is configured at the connection level

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26380?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-26380: ------------------------------------- Sprint: devex #155 September 2018 > pod log command does not work if oc is configured at the connection level > ------------------------------------------------------------------------- > > Key: JBIDE-26380 > URL: https://issues.jboss.org/browse/JBIDE-26380 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.9.0.AM3 > Reporter: Jeff MAURY > Assignee: Andre Dietisheim > Labels: connection, oc_binary, pod_log > Fix For: 4.9.0.Final > > Attachments: screenshot-1.png > > > ASSERT: no oc configured at the workspace level > ASSERT: oc is configured at the connection level > ASSERT: have a pod running > ASSERT: execute the pod log command > EXPECTED: pod log is shown > Instead, a dialog is shown claiming there is an issue with the oc client -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24769) Determine how to harmonize (or not) test structure between Fuse Tooling and JBoss Tools

by Tomáš Sedmík (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24769?page=com.atlassian.jira.plugi... ] Tomáš Sedmík closed JBIDE-24769. -------------------------------- closing - won't do > Determine how to harmonize (or not) test structure between Fuse Tooling and JBoss Tools > --------------------------------------------------------------------------------------- > > Key: JBIDE-24769 > URL: https://issues.jboss.org/browse/JBIDE-24769 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: fusetools, fusetools-extras > Affects Versions: 4.5.0.Final > Reporter: Aurélien Pupier > Fix For: 4.9.x > > > as reported in initial document here https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo... > The differences are explained in this old thread http://lists.jboss.org/pipermail/jbosstools-dev/2016-January/010908.html > I gave a talk @EclipseCon on the subject: https://www.youtube.com/watch?v=IGkFy2H-d60 > To make it short: > Fuse Tooling: > - "unit test" are at class level --> plugin named *.tests, test named *Test > - "integration test" are at osgi level --> plugin named *.tests.integration, test named *IT > Jboss Tools: > - "unit test" are at osgi level --> plugin named *.tests; test named *Test > - "integration test" are also at osgi level but with more complex requirements on environment -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26380) pod log command does not work if oc is configured at the connection level

by Jeff MAURY (JIRA)

Jeff MAURY created JBIDE-26380: ---------------------------------- Summary: pod log command does not work if oc is configured at the connection level Key: JBIDE-26380 URL: https://issues.jboss.org/browse/JBIDE-26380 Project: Tools (JBoss Tools) Issue Type: Bug Components: openshift Affects Versions: 4.9.0.AM3 Reporter: Jeff MAURY Assignee: Andre Dietisheim Fix For: 4.9.0.Final Attachments: screenshot-1.png ASSERT: no oc configured at the workspace level ASSERT: oc is configured at the connection level ASSERT: have a pod running ASSERT: execute the pod log command EXPECTED: pod log is shown Instead, a dialog is shown claiming there is an issue with the oc client -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26380) pod log command does not work if oc is configured at the connection level

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26380?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-26380: ------------------------------- Attachment: screenshot-1.png > pod log command does not work if oc is configured at the connection level > ------------------------------------------------------------------------- > > Key: JBIDE-26380 > URL: https://issues.jboss.org/browse/JBIDE-26380 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.9.0.AM3 > Reporter: Jeff MAURY > Assignee: Andre Dietisheim > Fix For: 4.9.0.Final > > Attachments: screenshot-1.png > > > ASSERT: no oc configured at the workspace level > ASSERT: oc is configured at the connection level > ASSERT: have a pod running > ASSERT: execute the pod log command > EXPECTED: pod log is shown > Instead, a dialog is shown claiming there is an issue with the oc client -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ERT-666) Improve JDT Indexer performance for method reference lookups

by Roland Grunberg (JIRA)

[ https://issues.jboss.org/browse/ERT-666?page=com.atlassian.jira.plugin.sy... ] Roland Grunberg updated ERT-666: -------------------------------- Description: Based on discussions with Igor, various proposals were made to improve the method reference lookup times of the JDT Indexer. One particular suggestion, which should be possible, with least amount of friction, would be to provide more information about the declaring type of a method in the indexer format. The methodRef category table currently stores : (symbol, number of arguments) -> document numbers (classfiles) toString/0 -> [1, 4, 5, 25] The proposal would change this to : (symbol, symbol's classname, classname) -> document numbers (classfiles) toString/0/java.lang.Object -> [1, 4, 5, 25] Doing so should reduce the number of post-processing changes needed to verify that the declaring type of the first set of matches corresponds to the declaring type of the selected reference. (/) Make the patch mostly correct (/) Basic performance test with just a JVM target platform, and lookup of java.lang.Object.toString() (?) Detect method references even in dead code (this is supported by existing indexer) (?) More complicated performance test against the Eclipse Platform itself for java.lang.Object.toString() (?) A more thorough correctness test to identify any additional differences. (eg. test every single possible method reference, not just toString() ) Upstream Bug : https://bugs.eclipse.org/bugs/show_bug.cgi?id=539159 was: Based on discussions with Igor, various proposals were made to improve the method reference lookup times of the JDT Indexer. One particular suggestion, which should be possible, with least amount of friction, would be to provide more information about the declaring type of a method in the indexer format. The methodRef category table currently stores : (symbol, number of arguments) -> document numbers (classfiles) toString/0 -> [1, 4, 5, 25] The proposal would change this to : (symbol, symbol's classname, classname) -> document numbers (classfiles) toString/0/java.lang.Object -> [1, 4, 5, 25] Doing so should reduce the number of post-processing changes needed to verify that the declaring type of the first set of matches corresponds to the declaring type of the selected reference. (/) Make the patch mostly correct (/) Basic performance test with just a JVM target platform, and lookup of java.lang.Object.toString() (?) Detect method references even in dead code (this is supported by existing indexer) (?) More complicated performance test against the Eclipse Platform itself for java.lang.Object.toString() (?) A more thorough correctness test to identify any additional differences. (eg. test every single possible method reference, not just toString() ) > Improve JDT Indexer performance for method reference lookups > ------------------------------------------------------------ > > Key: ERT-666 > URL: https://issues.jboss.org/browse/ERT-666 > Project: Eclipse Release Train > Issue Type: Task > Reporter: Roland Grunberg > Assignee: Roland Grunberg > > Based on discussions with Igor, various proposals were made to improve the method reference lookup times of the JDT Indexer. > One particular suggestion, which should be possible, with least amount of friction, would be to provide more information about the declaring type of a method in the indexer format. > The methodRef category table currently stores : > (symbol, number of arguments) -> document numbers (classfiles) > toString/0 -> [1, 4, 5, 25] > The proposal would change this to : > (symbol, symbol's classname, classname) -> document numbers (classfiles) > toString/0/java.lang.Object -> [1, 4, 5, 25] > Doing so should reduce the number of post-processing changes needed to verify that the declaring type of the first set of matches corresponds to the declaring type of the selected reference. > (/) Make the patch mostly correct > (/) Basic performance test with just a JVM target platform, and lookup of java.lang.Object.toString() > (?) Detect method references even in dead code (this is supported by existing indexer) > (?) More complicated performance test against the Eclipse Platform itself for java.lang.Object.toString() > (?) A more thorough correctness test to identify any additional differences. (eg. test every single possible method reference, not just toString() ) > Upstream Bug : https://bugs.eclipse.org/bugs/show_bug.cgi?id=539159 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26357) JMX MBean Tree is auto collapsing when walking down the tree items of EAP 7.1 server adapter

by Ondrej Dockal (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26357?page=com.atlassian.jira.plugi... ] Ondrej Dockal reassigned JBIDE-26357: ------------------------------------- Assignee: Rob Stryker > JMX MBean Tree is auto collapsing when walking down the tree items of EAP 7.1 server adapter > -------------------------------------------------------------------------------------------- > > Key: JBIDE-26357 > URL: https://issues.jboss.org/browse/JBIDE-26357 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jmx > Affects Versions: 4.9.0.AM3 > Reporter: Ondrej Dockal > Assignee: Rob Stryker > Attachments: JMXServerConnectionAutoCollapseIssue.gif > > > JMX MBean tree in JMX Navigator do autocollapse when walking the tree items. When I go for an item twice, it will not collapse only on first time. I am not sure about reproducing the issue as I got it when using EAP server adapter. Wildfly is not doing it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ERT-667) [GTK2] Remove GTK 2.x support [EBZ#530841]

by Eric Williams (JIRA)

[ https://issues.jboss.org/browse/ERT-667?page=com.atlassian.jira.plugin.sy... ] Eric Williams updated ERT-667: ------------------------------ Sprint: devex #155 September 2018 > [GTK2] Remove GTK 2.x support [EBZ#530841] > ------------------------------------------ > > Key: ERT-667 > URL: https://issues.jboss.org/browse/ERT-667 > Project: Eclipse Release Train > Issue Type: Task > Components: Platform > Reporter: Friendly Jira Robot > Assignee: Eric Williams > Labels: SWT, bzira > > TL;DR: Gtk 2.x bugs are not investigated anymore. Please submit Gtk3* show stoppers to Bug 527444 instead. > Reason: > Gtk 2.x is getting old and a number of underlying libraries are getting changes which are not tested with it anymore. The fact that it relies on Webkit 1.x API which is not shipped with newer Linux distributions makes the Browser component on GTK 2.x useless quite often. This makes it increasingly difficult to maintain it. Almost all new Linux distributions provide Gtk 3.x with Webkit 2. > As such effort is focused on improving Gtk 3.x and Wayland support. > Gtk 2.x-only bugs are set to have Priority of P5, indicating that bugs exist, but will not be investigated by committers. Patches welcome though! > FAQ: > 1) Question: "I rely on Gtk 2.x because of bug XYZ in Gtk 3x". > Answer: Focus is on resolving any 'gtk3' show stoppers that you may be experiencing. If you have a bug that stops you from moving to Gtk 3.x, please mention it in the gtk3 show stopper tracker (below) and we will do our best to address the bug in question: > Bug 527444 [GTK3] Umbrella bug for GTK3 showstoppers > https://bugs.eclipse.org/bugs/show_bug.cgi?id=527444 > 2) Question: "Gtk3 doesn't look proper on my gtk3 theme" > Answer: Unfortunatley we don't have the man power to test/fix eclipse against every Gtk 3.x theme out there. Further a lot of the Gtk 3.x themes are pretty buggy, such bugs are out of our control. > 'Adwaita' (light & dark) which is the default Gtk3/Gnome theme is the recommended choice for best results. > Note, Gtk underwent a lot of theming changes. Gtk 3.22 is currently the most stable for themes. > Note, 'Oxygen-gtk' theme engine is know to cause a lot of breakage and Gtk currently doesn't support it either. > This bug is in place to provide information on Gtk2 status. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ERT-667) [GTK2] Remove GTK 2.x support [EBZ#530841]

by Eric Williams (JIRA)

[ https://issues.jboss.org/browse/ERT-667?page=com.atlassian.jira.plugin.sy... ] Eric Williams reassigned ERT-667: --------------------------------- Assignee: Eric Williams > [GTK2] Remove GTK 2.x support [EBZ#530841] > ------------------------------------------ > > Key: ERT-667 > URL: https://issues.jboss.org/browse/ERT-667 > Project: Eclipse Release Train > Issue Type: Task > Components: Platform > Reporter: Friendly Jira Robot > Assignee: Eric Williams > Labels: SWT, bzira > > TL;DR: Gtk 2.x bugs are not investigated anymore. Please submit Gtk3* show stoppers to Bug 527444 instead. > Reason: > Gtk 2.x is getting old and a number of underlying libraries are getting changes which are not tested with it anymore. The fact that it relies on Webkit 1.x API which is not shipped with newer Linux distributions makes the Browser component on GTK 2.x useless quite often. This makes it increasingly difficult to maintain it. Almost all new Linux distributions provide Gtk 3.x with Webkit 2. > As such effort is focused on improving Gtk 3.x and Wayland support. > Gtk 2.x-only bugs are set to have Priority of P5, indicating that bugs exist, but will not be investigated by committers. Patches welcome though! > FAQ: > 1) Question: "I rely on Gtk 2.x because of bug XYZ in Gtk 3x". > Answer: Focus is on resolving any 'gtk3' show stoppers that you may be experiencing. If you have a bug that stops you from moving to Gtk 3.x, please mention it in the gtk3 show stopper tracker (below) and we will do our best to address the bug in question: > Bug 527444 [GTK3] Umbrella bug for GTK3 showstoppers > https://bugs.eclipse.org/bugs/show_bug.cgi?id=527444 > 2) Question: "Gtk3 doesn't look proper on my gtk3 theme" > Answer: Unfortunatley we don't have the man power to test/fix eclipse against every Gtk 3.x theme out there. Further a lot of the Gtk 3.x themes are pretty buggy, such bugs are out of our control. > 'Adwaita' (light & dark) which is the default Gtk3/Gnome theme is the recommended choice for best results. > Note, Gtk underwent a lot of theming changes. Gtk 3.22 is currently the most stable for themes. > Note, 'Oxygen-gtk' theme engine is know to cause a lot of breakage and Gtk currently doesn't support it either. > This bug is in place to provide information on Gtk2 status. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBDS-4730) [Rebranding] Use "Red Hat CodeReady Studio" instead of "Red Hat Developer Studio" in graphics & text

by James Cobb (JIRA)

[ https://issues.jboss.org/browse/JBDS-4730?page=com.atlassian.jira.plugin.... ] James Cobb commented on JBDS-4730: ---------------------------------- [~rpdavis] - Jessica Burkitt from brand stated otherwise as with the my previous comment. "All of these product names should follow this naming structure: Master Brand + Sub Brand + Product Name + optional modifier so the new name would be: *Red Hat Code Ready Developer Studio*" They also state that Code Ready is to always be two words. The GitLab conversation seems to only be the project team. Perhaps there needs to be a larger conversation between y'all and Brand because it is Brand that will be creating the official logo files for the products. Here is the "global" Red Hat Code Ready logo... https://pnt.redhat.com/pnt/p-10121965/RH_Logo_Code_...RGB_Black.png > [Rebranding] Use "Red Hat CodeReady Studio" instead of "Red Hat Developer Studio" in graphics & text > ---------------------------------------------------------------------------------------------------- > > Key: JBDS-4730 > URL: https://issues.jboss.org/browse/JBDS-4730 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Task > Components: build, installer > Affects Versions: 12.9.0.AM3 > Reporter: Nick Boldt > Assignee: James Cobb > Priority: Blocker > Fix For: 12.10.0.AM1 > > > Branding has requested that we rename devstudio from "Red Hat Developer Studio" to "Red Hat CodeReady Studio". > As we did recently in JBDS-4706, we'll need to collect graphics for use in the product and its website on https://devstudio.redhat.com/12/staging/updates/ > We'll need this rebrand done for the upcoming December release. All changes need to be done by November 6 so they can be included in the AM1 feature complete release on Nov 13, in support of the docs team, updating screenshots, install instructions, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBDS-4730) [Rebranding] Use "Red Hat CodeReady Studio" instead of "Red Hat Developer Studio" in graphics & text

by Bob Davis (JIRA)

[ https://issues.jboss.org/browse/JBDS-4730?page=com.atlassian.jira.plugin.... ] Bob Davis commented on JBDS-4730: --------------------------------- The GitLab conversation is correct. Red Hat CodeReady Studio is the "official" name. Short name is "CodeReady Studio" Bob > [Rebranding] Use "Red Hat CodeReady Studio" instead of "Red Hat Developer Studio" in graphics & text > ---------------------------------------------------------------------------------------------------- > > Key: JBDS-4730 > URL: https://issues.jboss.org/browse/JBDS-4730 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Task > Components: build, installer > Affects Versions: 12.9.0.AM3 > Reporter: Nick Boldt > Assignee: James Cobb > Priority: Blocker > Fix For: 12.10.0.AM1 > > > Branding has requested that we rename devstudio from "Red Hat Developer Studio" to "Red Hat CodeReady Studio". > As we did recently in JBDS-4706, we'll need to collect graphics for use in the product and its website on https://devstudio.redhat.com/12/staging/updates/ > We'll need this rebrand done for the upcoming December release. All changes need to be done by November 6 so they can be included in the AM1 feature complete release on Nov 13, in support of the docs team, updating screenshots, install instructions, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues September 2018