September 2018 - jbosstools-issues

[JBoss JIRA] (JBIDE-26148) CommandLocationBinary: only searches once (wont retry if it fails, forcing me to restart Eclipse once I corrected a broken link)

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26148?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-26148 at 9/6/18 4:56 AM: ------------------------------------------------------------------ [~rob.stryker] If some kind of a trigger in preferences (like a button, a link, etc.) where the user can force a renewed search is what you're suggesting, then I'm all +1. Thinking this issue through again made me believe that the edge case that we can fix here makes this a non-critical, non-urgent issue. was (Author: adietish): [~rob.stryker] If some kind of a trigger in preferences (like a button, a link, etc.) where the user can force a renewed search is what you're suggesting, then I'm all +1. Thinking this issue through again made me think that the edge case that we can fix makes this a non-critical, non-urgent issue. > CommandLocationBinary: only searches once (wont retry if it fails, forcing me to restart Eclipse once I corrected a broken link) > -------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-26148 > URL: https://issues.jboss.org/browse/JBIDE-26148 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.6.0.AM3 > Reporter: Andre Dietisheim > Assignee: Rob Stryker > Fix For: 4.9.x > > > [CommandLocationBinary|https://github.com/adietish/jbosstools-openshift/bl...] allows to lookup a command (on the $PATH, etc.). But it'll only do so once: > {code:title=CommandLocationBinary} > public String findLocation(int timeout) { > if (foundLoc != null || searchFailed) > return foundLoc; > String searched = CommandLocationLookupStrategy.get().search(this, timeout); > if (searched == null) { > searchFailed = true; > } > foundLoc = searched; > return searched; > } > {code} > Once the lookup failed, it'll store this in the var *searchFailed* and wont do it a 2nd time. > What if I update my ex. correct a broken link to oc while I keep Eclipse running? > I'd think that one should be able to repeat the lookup if it fails since the user could modify it's system while he keeps Eclipse running. Afaics the current impl forces me to restart Eclipse. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26148) CommandLocationBinary: only searches once (wont retry if it fails, forcing me to restart Eclipse once I corrected a broken link)

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26148?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-26148: ------------------------------------------ [~rob.stryker] If some kind of a trigger in preferences (like a button, a link, etc.) where the user can force a renewed search is what you're suggesting, then I'm all +1. Thinking this issue through again made me think that the edge case that we can fix makes this a non-critical, non-urgent issue. > CommandLocationBinary: only searches once (wont retry if it fails, forcing me to restart Eclipse once I corrected a broken link) > -------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-26148 > URL: https://issues.jboss.org/browse/JBIDE-26148 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.6.0.AM3 > Reporter: Andre Dietisheim > Assignee: Rob Stryker > Fix For: 4.9.x > > > [CommandLocationBinary|https://github.com/adietish/jbosstools-openshift/bl...] allows to lookup a command (on the $PATH, etc.). But it'll only do so once: > {code:title=CommandLocationBinary} > public String findLocation(int timeout) { > if (foundLoc != null || searchFailed) > return foundLoc; > String searched = CommandLocationLookupStrategy.get().search(this, timeout); > if (searched == null) { > searchFailed = true; > } > foundLoc = searched; > return searched; > } > {code} > Once the lookup failed, it'll store this in the var *searchFailed* and wont do it a 2nd time. > What if I update my ex. correct a broken link to oc while I keep Eclipse running? > I'd think that one should be able to repeat the lookup if it fails since the user could modify it's system while he keeps Eclipse running. Afaics the current impl forces me to restart Eclipse. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26148) CommandLocationBinary: only searches once (wont retry if it fails, forcing me to restart Eclipse once I corrected a broken link)

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26148?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-26148: ------------------------------------- Fix Version/s: 4.9.x > CommandLocationBinary: only searches once (wont retry if it fails, forcing me to restart Eclipse once I corrected a broken link) > -------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-26148 > URL: https://issues.jboss.org/browse/JBIDE-26148 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.6.0.AM3 > Reporter: Andre Dietisheim > Assignee: Rob Stryker > Fix For: 4.9.x > > > [CommandLocationBinary|https://github.com/adietish/jbosstools-openshift/bl...] allows to lookup a command (on the $PATH, etc.). But it'll only do so once: > {code:title=CommandLocationBinary} > public String findLocation(int timeout) { > if (foundLoc != null || searchFailed) > return foundLoc; > String searched = CommandLocationLookupStrategy.get().search(this, timeout); > if (searched == null) { > searchFailed = true; > } > foundLoc = searched; > return searched; > } > {code} > Once the lookup failed, it'll store this in the var *searchFailed* and wont do it a 2nd time. > What if I update my ex. correct a broken link to oc while I keep Eclipse running? > I'd think that one should be able to repeat the lookup if it fails since the user could modify it's system while he keeps Eclipse running. Afaics the current impl forces me to restart Eclipse. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26336) Upgrade jacoco version to 0.8.2+ to be compatible with Java 11

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26336?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-26336: ------------------------------- Component/s: build > Upgrade jacoco version to 0.8.2+ to be compatible with Java 11 > -------------------------------------------------------------- > > Key: JBIDE-26336 > URL: https://issues.jboss.org/browse/JBIDE-26336 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.9.0.AM3 > Reporter: Aurélien Pupier > Fix For: 4.9.0.Final > > > https://github.com/jacoco/jacoco/releases/tag/v0.8.2 > {quote}Experimental support for Java 11 and Java 12 class files, including JEP 12 "preview features" (GitHub #719, #738, #743).{quote} > for now for SAp Tooling, I got > {noformat} > 09:37:54 Exception in thread "main" java.lang.reflect.InvocationTargetException > 09:37:54 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > 09:37:54 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > 09:37:54 at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > 09:37:54 at java.base/java.lang.reflect.Method.invoke(Method.java:566) > 09:37:54 at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:513) > 09:37:54 at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:525) > 09:37:54 Caused by: java.lang.RuntimeException: Class java/lang/UnknownError could not be instrumented. > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:140) > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:101) > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.PreMain.createRuntime(PreMain.java:55) > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.PreMain.premain(PreMain.java:47) > 09:37:54 ... 6 more > 09:37:54 Caused by: java.lang.NoSuchFieldException: $jacocoAccess > 09:37:54 at java.base/java.lang.Class.getField(Class.java:2000) > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:138) > 09:37:54 ... 9 more > 09:37:54 FATAL ERROR in native method: processing of -javaagent failed > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26336) Upgrade jacoco version to 0.8.2+ to be compatible with Java 11

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26336?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-26336: ------------------------------- Affects Version/s: 4.9.0.AM3 > Upgrade jacoco version to 0.8.2+ to be compatible with Java 11 > -------------------------------------------------------------- > > Key: JBIDE-26336 > URL: https://issues.jboss.org/browse/JBIDE-26336 > Project: Tools (JBoss Tools) > Issue Type: Task > Affects Versions: 4.9.0.AM3 > Reporter: Aurélien Pupier > Fix For: 4.9.0.Final > > > https://github.com/jacoco/jacoco/releases/tag/v0.8.2 > {quote}Experimental support for Java 11 and Java 12 class files, including JEP 12 "preview features" (GitHub #719, #738, #743).{quote} > for now for SAp Tooling, I got > {noformat} > 09:37:54 Exception in thread "main" java.lang.reflect.InvocationTargetException > 09:37:54 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > 09:37:54 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > 09:37:54 at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > 09:37:54 at java.base/java.lang.reflect.Method.invoke(Method.java:566) > 09:37:54 at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:513) > 09:37:54 at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:525) > 09:37:54 Caused by: java.lang.RuntimeException: Class java/lang/UnknownError could not be instrumented. > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:140) > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:101) > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.PreMain.createRuntime(PreMain.java:55) > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.PreMain.premain(PreMain.java:47) > 09:37:54 ... 6 more > 09:37:54 Caused by: java.lang.NoSuchFieldException: $jacocoAccess > 09:37:54 at java.base/java.lang.Class.getField(Class.java:2000) > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:138) > 09:37:54 ... 9 more > 09:37:54 FATAL ERROR in native method: processing of -javaagent failed > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26336) Upgrade jacoco version to 0.8.2+ to be compatible with Java 11

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26336?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-26336: ------------------------------- Fix Version/s: 4.9.0.Final > Upgrade jacoco version to 0.8.2+ to be compatible with Java 11 > -------------------------------------------------------------- > > Key: JBIDE-26336 > URL: https://issues.jboss.org/browse/JBIDE-26336 > Project: Tools (JBoss Tools) > Issue Type: Task > Affects Versions: 4.9.0.AM3 > Reporter: Aurélien Pupier > Fix For: 4.9.0.Final > > > https://github.com/jacoco/jacoco/releases/tag/v0.8.2 > {quote}Experimental support for Java 11 and Java 12 class files, including JEP 12 "preview features" (GitHub #719, #738, #743).{quote} > for now for SAp Tooling, I got > {noformat} > 09:37:54 Exception in thread "main" java.lang.reflect.InvocationTargetException > 09:37:54 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > 09:37:54 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > 09:37:54 at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > 09:37:54 at java.base/java.lang.reflect.Method.invoke(Method.java:566) > 09:37:54 at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:513) > 09:37:54 at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:525) > 09:37:54 Caused by: java.lang.RuntimeException: Class java/lang/UnknownError could not be instrumented. > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:140) > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:101) > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.PreMain.createRuntime(PreMain.java:55) > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.PreMain.premain(PreMain.java:47) > 09:37:54 ... 6 more > 09:37:54 Caused by: java.lang.NoSuchFieldException: $jacocoAccess > 09:37:54 at java.base/java.lang.Class.getField(Class.java:2000) > 09:37:54 at org.jacoco.agent.rt.internal_c13123e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:138) > 09:37:54 ... 9 more > 09:37:54 FATAL ERROR in native method: processing of -javaagent failed > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ERT-663) Display.getClientArea() includes toolbar on Linux [EBZ#33659]

by Eric Williams (JIRA)

[ https://issues.jboss.org/browse/ERT-663?page=com.atlassian.jira.plugin.sy... ] Eric Williams updated ERT-663: ------------------------------ Sprint: devex #154 September 2018 > Display.getClientArea() includes toolbar on Linux [EBZ#33659] > ------------------------------------------------------------- > > Key: ERT-663 > URL: https://issues.jboss.org/browse/ERT-663 > Project: Eclipse Release Train > Issue Type: Task > Components: Platform > Reporter: Friendly Jira Robot > Assignee: Eric Williams > Labels: SWT, bzira > > 20030227 > The client area on Linux Motif also includes the toolbar whereas on other > playforms it doesn't. > STEPS > 1) Set you display to 1024 x 768 > 2) Execute Display.getClientArea() > 3) Value us 1024,768 > 4) Switch to XP > 5) Execute Display.getClientArea() > 6) Value us 1024,738 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ERT-664) Orca and flat review problems [EBZ#536974]

by Eric Williams (JIRA)

[ https://issues.jboss.org/browse/ERT-664?page=com.atlassian.jira.plugin.sy... ] Eric Williams updated ERT-664: ------------------------------ Sprint: devex #154 September 2018 > Orca and flat review problems [EBZ#536974] > ------------------------------------------ > > Key: ERT-664 > URL: https://issues.jboss.org/browse/ERT-664 > Project: Eclipse Release Train > Issue Type: Task > Components: Platform > Reporter: Friendly Jira Robot > Assignee: Eric Williams > Labels: SWT, bzira > > I can not read information present in the screen using flat review mode. > The problem can be reproduced in various parts such as in the > editor, in the package explorer, project explorer and etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ERT-665) [GTK3] Breakpoint condition text editor has no cursor [EBZ#538590]

by Eric Williams (JIRA)

[ https://issues.jboss.org/browse/ERT-665?page=com.atlassian.jira.plugin.sy... ] Eric Williams updated ERT-665: ------------------------------ Sprint: devex #154 September 2018 > [GTK3] Breakpoint condition text editor has no cursor [EBZ#538590] > ------------------------------------------------------------------ > > Key: ERT-665 > URL: https://issues.jboss.org/browse/ERT-665 > Project: Eclipse Release Train > Issue Type: Task > Components: Platform > Reporter: Friendly Jira Robot > Assignee: Eric Williams > Labels: 4.9_RC2, SWT, bzira > Fix For: 2018-09 RC2 > > > To reproduce: > 1. Set breakpoint anywhere in Java code. > 2. Edit breakpoint. > 3. Enable breakpoint condition. > 4. Edit the condition. > 5. Observe that there is no text cursor. > Seen in: > Eclipse SDK > Version: 4.9 > Build id: I20180625-1545 > Not seen in: > Eclipse SDK > Version: Photon (4.8) > Build id: I20180611-0500 > Seen with RHEL 7.4, GTK 3.22.10. Not seen on Windows 7. > Text cursors are relatively basic functionality and very useful when writing any sort of text. Its somewhat odd to not have one, and it really harms editing the breakpoint condition. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ERT-665) [GTK3] Breakpoint condition text editor has no cursor [EBZ#538590]

by Eric Williams (JIRA)

[ https://issues.jboss.org/browse/ERT-665?page=com.atlassian.jira.plugin.sy... ] Eric Williams reassigned ERT-665: --------------------------------- Assignee: Eric Williams > [GTK3] Breakpoint condition text editor has no cursor [EBZ#538590] > ------------------------------------------------------------------ > > Key: ERT-665 > URL: https://issues.jboss.org/browse/ERT-665 > Project: Eclipse Release Train > Issue Type: Task > Components: Platform > Reporter: Friendly Jira Robot > Assignee: Eric Williams > Labels: 4.9_RC2, SWT, bzira > Fix For: 2018-09 RC2 > > > To reproduce: > 1. Set breakpoint anywhere in Java code. > 2. Edit breakpoint. > 3. Enable breakpoint condition. > 4. Edit the condition. > 5. Observe that there is no text cursor. > Seen in: > Eclipse SDK > Version: 4.9 > Build id: I20180625-1545 > Not seen in: > Eclipse SDK > Version: Photon (4.8) > Build id: I20180611-0500 > Seen with RHEL 7.4, GTK 3.22.10. Not seen on Windows 7. > Text cursors are relatively basic functionality and very useful when writing any sort of text. Its somewhat odd to not have one, and it really harms editing the breakpoint condition. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues September 2018