March 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-21782) Adding EAP 7. ER6 server rises a warning on New runtime page

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21782?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-21782: --------------------------------------- I forgot to add that I used JBoss EAP 7.0.0.DR7 from March 20. > Adding EAP 7. ER6 server rises a warning on New runtime page > ------------------------------------------------------------ > > Key: JBIDE-21782 > URL: https://issues.jboss.org/browse/JBIDE-21782 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.3.1.CR1 > Reporter: Radim Hopp > Assignee: Rob Stryker > Fix For: 4.3.1.CR1 > > > Screenshot: http://i.imgur.com/ObzrfQs.png > The warning is: > {noformat} > This server type expects a version of 6.1 but the server directory is of version 7.0.0.GA. This combination may cause critical errors. {noformat} > I guess it's because ER6 reports version "7.0.0.GA". > For example ER2 doesn't raise the warning (because it still reports as 7.0.0.Beta1). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-21782) Adding EAP 7. ER6 server rises a warning on New runtime page

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21782?page=com.atlassian.jira.plugi... ] Martin Malina closed JBIDE-21782. --------------------------------- Verified in latest JBDS 9.1.0.CR1 build. Runtime detection works also. > Adding EAP 7. ER6 server rises a warning on New runtime page > ------------------------------------------------------------ > > Key: JBIDE-21782 > URL: https://issues.jboss.org/browse/JBIDE-21782 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.3.1.CR1 > Reporter: Radim Hopp > Assignee: Rob Stryker > Fix For: 4.3.1.CR1 > > > Screenshot: http://i.imgur.com/ObzrfQs.png > The warning is: > {noformat} > This server type expects a version of 6.1 but the server directory is of version 7.0.0.GA. This combination may cause critical errors. {noformat} > I guess it's because ER6 reports version "7.0.0.GA". > For example ER2 doesn't raise the warning (because it still reports as 7.0.0.Beta1). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3689) ask user for JDK location when old location is gone

by Len DiMaggio (JIRA)

[ https://issues.jboss.org/browse/JBDS-3689?page=com.atlassian.jira.plugin.... ] Len DiMaggio commented on JBDS-3689: ------------------------------------ FYI - A user can easily get into this situation by simply updating their JDK (yum update, etc.) - if the path changes to reflect the updated version number. > ask user for JDK location when old location is gone > --------------------------------------------------- > > Key: JBDS-3689 > URL: https://issues.jboss.org/browse/JBDS-3689 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Enhancement > Components: installer, upstream > Affects Versions: 9.1.0.Beta2 > Environment: Fedora 23 > Reporter: Aleksandar Kostadinov > Assignee: Denis Golovin > Fix For: 10.0.0.Alpha1 > > > Hello, installed 9.1.0.Beta2 and starting it after some fedora update, yielded an error that JDK is not found. With no help how to fix. > Searching over the internet I found > https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Developer_Stu... > But it makes much more sense to let the user select a different location. Or at least point user at the ini file to be updated. Currently user is left wondering why JBDS fails to start when system has a perfectly working JDK installed on standard location. My first thought was that for some reason JBDS installation broke. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3607) Rebrand Suite installer

by Joshua Wilson (JIRA)

[ https://issues.jboss.org/browse/JBDS-3607?page=com.atlassian.jira.plugin.... ] Joshua Wilson updated JBDS-3607: -------------------------------- Description: Suite Installer should use Red Hat Developer style. more details to follow. https://patternfly.atlassian.net/browse/RHUAP-26 was:Suite Installer should use Red Hat Developer style. more details to follow. > Rebrand Suite installer > ----------------------- > > Key: JBDS-3607 > URL: https://issues.jboss.org/browse/JBDS-3607 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Task > Components: installer > Reporter: Max Rydahl Andersen > Assignee: Joshua Wilson > Priority: Blocker > Labels: havoc, ui > Fix For: 9.1.0.CR1 > > > Suite Installer should use Red Hat Developer style. more details to follow. > https://patternfly.atlassian.net/browse/RHUAP-26 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3689) ask user for JDK location when old location is gone

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBDS-3689?page=com.atlassian.jira.plugin.... ] Alexey Kazakov updated JBDS-3689: --------------------------------- Fix Version/s: 10.0.0.Alpha1 (was: 4.4) > ask user for JDK location when old location is gone > --------------------------------------------------- > > Key: JBDS-3689 > URL: https://issues.jboss.org/browse/JBDS-3689 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Enhancement > Components: installer, upstream > Affects Versions: 9.1.0.Beta2 > Environment: Fedora 23 > Reporter: Aleksandar Kostadinov > Assignee: Mickael Istria > Fix For: 10.0.0.Alpha1 > > > Hello, installed 9.1.0.Beta2 and starting it after some fedora update, yielded an error that JDK is not found. With no help how to fix. > Searching over the internet I found > https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Developer_Stu... > But it makes much more sense to let the user select a different location. Or at least point user at the ini file to be updated. Currently user is left wondering why JBDS fails to start when system has a perfectly working JDK installed on standard location. My first thought was that for some reason JBDS installation broke. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3689) ask user for JDK location when old location is gone

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBDS-3689?page=com.atlassian.jira.plugin.... ] Alexey Kazakov reassigned JBDS-3689: ------------------------------------ Assignee: Denis Golovin (was: Mickael Istria) > ask user for JDK location when old location is gone > --------------------------------------------------- > > Key: JBDS-3689 > URL: https://issues.jboss.org/browse/JBDS-3689 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Enhancement > Components: installer, upstream > Affects Versions: 9.1.0.Beta2 > Environment: Fedora 23 > Reporter: Aleksandar Kostadinov > Assignee: Denis Golovin > Fix For: 10.0.0.Alpha1 > > > Hello, installed 9.1.0.Beta2 and starting it after some fedora update, yielded an error that JDK is not found. With no help how to fix. > Searching over the internet I found > https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Developer_Stu... > But it makes much more sense to let the user select a different location. Or at least point user at the ini file to be updated. Currently user is left wondering why JBDS fails to start when system has a perfectly working JDK installed on standard location. My first thought was that for some reason JBDS installation broke. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3689) ask user for JDK location when old location is gone

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBDS-3689?page=com.atlassian.jira.plugin.... ] Alexey Kazakov updated JBDS-3689: --------------------------------- Component/s: installer > ask user for JDK location when old location is gone > --------------------------------------------------- > > Key: JBDS-3689 > URL: https://issues.jboss.org/browse/JBDS-3689 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Enhancement > Components: installer, upstream > Affects Versions: 9.1.0.Beta2 > Environment: Fedora 23 > Reporter: Aleksandar Kostadinov > Assignee: Mickael Istria > Fix For: 4.4 > > > Hello, installed 9.1.0.Beta2 and starting it after some fedora update, yielded an error that JDK is not found. With no help how to fix. > Searching over the internet I found > https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Developer_Stu... > But it makes much more sense to let the user select a different location. Or at least point user at the ini file to be updated. Currently user is left wondering why JBDS fails to start when system has a perfectly working JDK installed on standard location. My first thought was that for some reason JBDS installation broke. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBDS-3689) ask user for JDK location when old location is gone

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBDS-3689?page=com.atlassian.jira.plugin.... ] Alexey Kazakov commented on JBDS-3689: -------------------------------------- First at all this is not purely JBDS specific. This is a documented Eclipse feature we use in JBDS. Despite the way we go in JBDS, Eclipse could behave better and at least give more details to the user how the problem with missing JVM can be fixed. And we can't just get rid of -vm for JBDS completely because the default JVM can be incompatible with JBDS. But what we can/should do is to not set -vm if users chose the default JVM during the installation. So I see here two issues: #1 Upstream one. Eclipse doesn't suggest to change -vm in the *.ini file to fix the problem. [~mickael_istria] can you report it to Eclipse? #2 JBDS installer should not set -vm if the default JVM is used. Assigning this to [~dgolovin]. > ask user for JDK location when old location is gone > --------------------------------------------------- > > Key: JBDS-3689 > URL: https://issues.jboss.org/browse/JBDS-3689 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Enhancement > Components: upstream > Affects Versions: 9.1.0.Beta2 > Environment: Fedora 23 > Reporter: Aleksandar Kostadinov > Assignee: Mickael Istria > Fix For: 4.4 > > > Hello, installed 9.1.0.Beta2 and starting it after some fedora update, yielded an error that JDK is not found. With no help how to fix. > Searching over the internet I found > https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Developer_Stu... > But it makes much more sense to let the user select a different location. Or at least point user at the ini file to be updated. Currently user is left wondering why JBDS fails to start when system has a perfectly working JDK installed on standard location. My first thought was that for some reason JBDS installation broke. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBTIS-604) Add tests for 'is async' feature

by Jozef Marko (JIRA)

Jozef Marko created JBTIS-604: --------------------------------- Summary: Add tests for 'is async' feature Key: JBTIS-604 URL: https://issues.jboss.org/browse/JBTIS-604 Project: JBoss Tools Integration Stack Issue Type: Task Affects Versions: 4.3.0.Beta1, 4.2.5.Final Reporter: Jozef Marko -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBIDE-21920) Cannot use features which are using oc binary

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21920?page=com.atlassian.jira.plugi... ] Fred Bricon reassigned JBIDE-21920: ----------------------------------- Assignee: Fred Bricon > Cannot use features which are using oc binary > --------------------------------------------- > > Key: JBIDE-21920 > URL: https://issues.jboss.org/browse/JBIDE-21920 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.CR1 > Reporter: Marián Labuda > Assignee: Fred Bricon > Priority: Blocker > Labels: openshift_v3 > Fix For: 4.3.1.CR1 > > > After latest update of nightly JBT I am not able to get logs from pods(/builds) or work with server adapter, because there is something wrong with setting oc path. When I set path on OpenShift 3 preference page to be pointing to correct oc binary, following e.g. getting log from pod results in showing following message in console > {code} > The OpenShift 'oc' binary location was not specified. Set the property openshift.restclient.oc.location > {code} > There is no stack trace available for this error in error log. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

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 March 2016