December 2014 - jbosstools-issues

[JBoss JIRA] (JBIDE-18855) Update Birt versions to 4.4.1 from 4.4.0 in the JBT unified TP

by Paul Leacu (JIRA)

Paul Leacu created JBIDE-18855: ---------------------------------- Summary: Update Birt versions to 4.4.1 from 4.4.0 in the JBT unified TP Key: JBIDE-18855 URL: https://issues.jboss.org/browse/JBIDE-18855 Project: Tools (JBoss Tools) Issue Type: Bug Components: target-platform Reporter: Paul Leacu *Reason:* You pull an updated version of Luna SR1a for use in your 4.41.x target platform, but still include the old BIRT 4.4.0 when there's a 4.4.1 version here? http://download.jboss.org/jbosstools/updates/requirements/luna/2014092610... *Project page/sources:* ... *Version:* 4.41.1.CR1 *License and owner:* JBoss *Original p2 repo:* http://third-party-vendor.com/path/to/updates-site/ *JBoss mirror:* http://downloads.jboss.org/jbosstools/updates/requirements/<projectName> *Include Sources:* No *Affected projects:* JBTIS TP *Include in JBDS:* Yes *Type of dependency:* distribution *List of bundles added/removed:* {code} suggested diff on the .target files {code} These features: <unit id="org.eclipse.birt.feature.group" version="4.4.0.v201405191524-DPEp7FGixAot6DLz0hXcUqaHoLSX"/> <unit id="org.eclipse.birt.chart.feature.group" version="4.4.0.v201405191524-829A4FQCnvK65Q9sKwwG"/> <unit id="org.eclipse.birt.integration.wtp.feature.group" version="4.4.0.v20140521-1030-53-7w3125163202141"/> <unit id="org.eclipse.birt.chart.integration.wtp.feature.group" version="4.4.0.v20140521-1030-53-7w3125163202141"/> Should pick up the 4.4.1... versions as seen here: http://download.jboss.org/jbosstools/updates/requirements/luna/2014092610... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18837) because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-18837: --------------------------------------------- I definitely would prefer the version gets to be independent of parent pom and i'm not fully grokking how you suggest to do it using base root pom version thus a PR would be helpful for sure. Aside: Its not new QE (or others) use nightlies and it is also not new that in *very* special cases QE need to rely on -D to test specific setups - we have done that all former releases. I don't think there would ever be need to differentiate between latest nightly for 4.2.x and latest staged for 4.2.x - that would be extreme exceptional cases and in all this it would still require using exact timestamps in ide-properties to differentiate. And yes, there aren't an awesome silver bullet for this - I wish there were; but so far I think by decoupling from parent pom and try testing our way out of detecting if the version is properly bumped we have a solution that are not bullet proof (You can break the situation if you really are clever in install sequence of things) but that are Good Enough without being too rigid. > because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated > ------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-18837 > URL: https://issues.jboss.org/browse/JBIDE-18837 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build, central, common/jst/core, project-examples > Affects Versions: 4.2.1.CR1 > Reporter: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > When updating from 4.2.0 to 4.2.1, a user might decide to only update Central or Project Examples, and NOT update Foundation.core, which means his Eclipse will still think it's 4.2.0, not 4.2.1, and he might get the wrong version of central/examples. > Therefore we need manifest-level [4.2.1,) requirements on upstream foundation.core in examples and central, to force this lock-step updating. > And we need to use the maven enforcer plugin to fail the build if these versions get out of sync. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18837) because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen edited comment on JBIDE-18837 at 12/1/14 3:44 PM: ---------------------------------------------------------------------- I definitely would prefer the version gets to be independent of parent pom and i'm not fully grokking how you suggest to do it using base root pom version thus a PR would be helpful for sure. Aside: Its not new QE (or others) use nightlies and it is also not new that in *very* special cases QE need to rely on -D to test specific setups - we have done that all former releases when non-staged yet testing had to be done (by QE or dev). I don't think there would ever be need to differentiate between latest nightly for 4.2.x and latest staged for 4.2.x - that would be extreme exceptional cases and in all this it would still require using exact timestamps in ide-properties to differentiate. And yes, there aren't an awesome silver bullet for this - I wish there were; but so far I think by decoupling from parent pom and try testing our way out of detecting if the version is properly bumped we have a solution that are not bullet proof (You can break the situation if you really are clever in install sequence of things) but that are Good Enough without being too rigid. was (Author: maxandersen): I definitely would prefer the version gets to be independent of parent pom and i'm not fully grokking how you suggest to do it using base root pom version thus a PR would be helpful for sure. Aside: Its not new QE (or others) use nightlies and it is also not new that in *very* special cases QE need to rely on -D to test specific setups - we have done that all former releases. I don't think there would ever be need to differentiate between latest nightly for 4.2.x and latest staged for 4.2.x - that would be extreme exceptional cases and in all this it would still require using exact timestamps in ide-properties to differentiate. And yes, there aren't an awesome silver bullet for this - I wish there were; but so far I think by decoupling from parent pom and try testing our way out of detecting if the version is properly bumped we have a solution that are not bullet proof (You can break the situation if you really are clever in install sequence of things) but that are Good Enough without being too rigid. > because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated > ------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-18837 > URL: https://issues.jboss.org/browse/JBIDE-18837 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build, central, common/jst/core, project-examples > Affects Versions: 4.2.1.CR1 > Reporter: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > When updating from 4.2.0 to 4.2.1, a user might decide to only update Central or Project Examples, and NOT update Foundation.core, which means his Eclipse will still think it's 4.2.0, not 4.2.1, and he might get the wrong version of central/examples. > Therefore we need manifest-level [4.2.1,) requirements on upstream foundation.core in examples and central, to force this lock-step updating. > And we need to use the maven enforcer plugin to fail the build if these versions get out of sync. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3208) reorg/refactor directories for consistency across JBT/JBDS

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBDS-3208: ------------------------------------------- To be clear - the requirement is not necessarily that it is a composite of multiple nightly builds; it is just the simplest way I know of providing a *stable* url for the release train that does not change just because our branch name changes. i.e. /luna/nightly vs first its called luna/master then /luna/4.2.x And no, this does not mean I think master and 4.2.x are bad names for internal sanity - but the url we make public for nightly and/or snapshot testing makes sense to follow similar layout as our staging, development and stable sites for two reasons: A) so users/testers/developers don't need to changed URL's in their test eclipse installs B) the sites we test/build are as close to the real published content. > reorg/refactor directories for consistency across JBT/JBDS > ---------------------------------------------------------- > > Key: JBDS-3208 > URL: https://issues.jboss.org/browse/JBDS-3208 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: build > Affects Versions: 9.0.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 9.0.0.Alpha1 > > > Be it resolved - we should reorg directories for consistency across JBT/JBDS: > {code} > download.jboss.org > <earlyaccess,updates,discovery>/mars > /snapshots [replace nightly] > /staging [rename content for QE, moves to development when approved] > /development > /stable (updates/mars/stable is a pointer back into updates/mars) > drop /integration (not used) > builds/<jobname>/<buildid> > builds/<jobname>/composite*.xml for last 2 builds > targetplatforms/<type>/<version> > {code} > and > {code} > devstudio.redhat.com > <earlyaccess,updates,discovery>/9.0 > /snapshots > /staging > /development > /stable (updates/9.0/stable is a pointer back into updates/9.0) > builds/<jobname>/<buildid> > builds/<jobname>/composite*.xml for last 2 builds > targetplatforms/<type>/<version> > {code} > Further discussion in http://ether-man.rhcloud.com/p/build.next.20141112 > This would remove the idea of the composite staging site [1] and the composite install job [2], today used to determine when it's time to run the aggregate builds, in favour of a new p2diff mechanism for determining if aggregates should be published. See JBIDE-18742 and JBIDE-16970. > [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.2.... > [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18681) 'Invalid thread access' error in central during shutdown

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18681?page=com.atlassian.jira.plugi... ] Denis Golovin closed JBIDE-18681. --------------------------------- Applied fix still could have the same problems with lower probability, so it is really impossible to replicate manually now. I personally would just removed code from stop method, because the only scenario when it called is closing or restarting eclipse, manual stopping is not the case for regular eclipse usage. One more option would be register workbench listener http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.... and that would work always. Anyway closing it for now, because I am not able to replicate it manually anymore. > 'Invalid thread access' error in central during shutdown > -------------------------------------------------------- > > Key: JBIDE-18681 > URL: https://issues.jboss.org/browse/JBIDE-18681 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: central > Affects Versions: 4.2.0.Final > Reporter: Denis Golovin > Assignee: Snjezana Peco > Labels: need-info > Fix For: 4.2.1.CR1, 4.3.0.Alpha1 > > > {code}Caused by: org.eclipse.swt.SWTException: Invalid thread access > at org.eclipse.swt.SWT.error(SWT.java:4441) > at org.eclipse.swt.SWT.error(SWT.java:4356) > at org.eclipse.swt.SWT.error(SWT.java:4327) > at org.eclipse.swt.widgets.Display.error(Display.java:1083) > at org.eclipse.swt.widgets.Display.createDisplay(Display.java:840) > at org.eclipse.swt.widgets.Display.create(Display.java:823) > at org.eclipse.swt.graphics.Device.<init>(Device.java:130) > at org.eclipse.swt.widgets.Display.<init>(Display.java:714) > at org.eclipse.swt.widgets.Display.<init>(Display.java:705) > at org.eclipse.swt.widgets.Display.getDefault(Display.java:1403) > at org.jboss.tools.central.JBossCentralActivator.stop(JBossCentralActivator.java:215) > at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:827) > at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1) > at java.security.AccessController.doPrivileged(Native Method) > at org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:820) > ... 13 more{code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3208) reorg/refactor directories for consistency across JBT/JBDS

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-3208: ----------------------------- Summary: reorg/refactor directories for consistency across JBT/JBDS (was: reorg directories for consistency across JBT/JBDS) > reorg/refactor directories for consistency across JBT/JBDS > ---------------------------------------------------------- > > Key: JBDS-3208 > URL: https://issues.jboss.org/browse/JBDS-3208 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: build > Affects Versions: 9.0.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 9.0.0.Alpha1 > > > Be it resolved - we should reorg directories for consistency across JBT/JBDS: > {code} > download.jboss.org > <earlyaccess,updates,discovery>/mars > /snapshots [replace nightly] > /staging [rename content for QE, moves to development when approved] > /development > /stable (updates/mars/stable is a pointer back into updates/mars) > drop /integration (not used) > builds/<jobname>/<buildid> > builds/<jobname>/composite*.xml for last 2 builds > targetplatforms/<type>/<version> > {code} > and > {code} > devstudio.redhat.com > <earlyaccess,updates,discovery>/9.0 > /snapshots > /staging > /development > /stable (updates/9.0/stable is a pointer back into updates/9.0) > builds/<jobname>/<buildid> > builds/<jobname>/composite*.xml for last 2 builds > targetplatforms/<type>/<version> > {code} > Further discussion in http://ether-man.rhcloud.com/p/build.next.20141112 > This would remove the idea of the composite staging site [1] and the composite install job [2], today used to determine when it's time to run the aggregate builds, in favour of a new p2diff mechanism for determining if aggregates should be published. See JBIDE-18742 and JBIDE-16970. > [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.2.... > [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18837) because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-18837: ------------------------------------ OK, so at the moment, the master branch for Base's org.j.t.foundation.core plugin relies on parent pom version for its definition of jbosstools.version. If you want that changed to use Base's root pom version, let me know and I can create a new PR. Aside: I wasn't suggesting NEW -D flags. I was suggesting that under your new scheme, QE may need to revert to using the OLD flags, since you have no way to differentiate "latest nightly for 4.2.x" from "latest staged for 4.2.x". Since we've discovered that QE sometimes wants to test nightlies before they're staged (JBIDE-18833), we need a workaround for that use case. Being tied to parent pom version HELPS but it's not the silver bullet I'd like. > because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated > ------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-18837 > URL: https://issues.jboss.org/browse/JBIDE-18837 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build, central, common/jst/core, project-examples > Affects Versions: 4.2.1.CR1 > Reporter: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > When updating from 4.2.0 to 4.2.1, a user might decide to only update Central or Project Examples, and NOT update Foundation.core, which means his Eclipse will still think it's 4.2.0, not 4.2.1, and he might get the wrong version of central/examples. > Therefore we need manifest-level [4.2.1,) requirements on upstream foundation.core in examples and central, to force this lock-step updating. > And we need to use the maven enforcer plugin to fail the build if these versions get out of sync. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18852) No warning about missing invocation handler for interface

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18852?page=com.atlassian.jira.plugi... ] Alexey Kazakov reassigned JBIDE-18852: -------------------------------------- Assignee: Viacheslav Kabanovich > No warning about missing invocation handler for interface > --------------------------------------------------------- > > Key: JBIDE-18852 > URL: https://issues.jboss.org/browse/JBIDE-18852 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: cdi-extensions > Affects Versions: 4.2.1.CR1 > Reporter: Rastislav Wagner > Assignee: Viacheslav Kabanovich > Fix For: 4.3.0.Alpha1 > > > 1. Create CDI 1.1 project and add deltaspike libs > 2. create partial bean binding > {code} > @PartialBeanBinding > @Target(ElementType.TYPE) > @Retention(RetentionPolicy.RUNTIME) > public @interface ExamplePartialBeanBinding { > } > {code} > 3.create interface > {code} > import javax.enterprise.context.ApplicationScoped; > @ApplicationScoped > @ExamplePartialBeanBinding > public interface Interf { > String sayHello(String hello); > } > {code} > FAIL: There's no warning saying that class should have an invocation handler > 4. create abstract class > {code} > import javax.enterprise.context.ApplicationScoped; > @ApplicationScoped > @ExamplePartialBeanBinding > public abstract class Abs { > public abstract String sayHello(String hello); > public String otherHey (String hello) { > return "Other: " + hello; > } > } > {code} > ASSERT: warning about missing invocation handler is displayed for abstract class > 5. Check interface class again -> no warning, edit file & save -> warning is displayed -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18732) CordovaSim must save preferences (tabs / settings / etc.)

by Vlado Pakan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18732?page=com.atlassian.jira.plugi... ] Vlado Pakan commented on JBIDE-18732: ------------------------------------- QA feedback is in my previous comment. We don't test building from branches attached to PRs > CordovaSim must save preferences (tabs / settings / etc.) > --------------------------------------------------------- > > Key: JBIDE-18732 > URL: https://issues.jboss.org/browse/JBIDE-18732 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: cordovasim > Affects Versions: 4.2.0.Final, 4.3.0.Alpha1 > Reporter: Ilya Buziuk > Assignee: Ilya Buziuk > Labels: respin-a > Fix For: 4.2.1.CR1, 4.3.0.Alpha1 > > > For now all CordovaSim's preferences are hardcoded - https://github.com/jbosstools/incubator-ripple/commit/d2b46fdc5cfa74cc8c6... > CordovaSim must save all user's preferences: tab order, setting, etc. > NOTE: Preferences will *not* be saved for *javaFX* web engine oracle *JDK 7*, due to localstorage absence. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17818) Visual Editor: Need to handle external html / htm files

by Vlado Pakan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17818?page=com.atlassian.jira.plugi... ] Vlado Pakan commented on JBIDE-17818: ------------------------------------- QA will be able to test it with 4.2.1.CR1 build > Visual Editor: Need to handle external html / htm files > ------------------------------------------------------- > > Key: JBIDE-17818 > URL: https://issues.jboss.org/browse/JBIDE-17818 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: visual-page-editor-core > Affects Versions: 4.2.0.Beta2 > Reporter: Ilya Buziuk > Assignee: Konstantin Marmalyukov > Labels: new_and_noteworthy, respin-a > Fix For: 4.2.1.CR1 > > > Now VPE / HTML Preview can handle only workspace's files. Need to add external files support > When I open html pages outside eclipse workspace I get an error stating VPE preview cannot open the file. > That is not ok. > preview should be able to just fine preview the html no matter where the content is from and if it is because some current limitation about preview then users should at least be able to edit files even if external to the workspace. > by external to workspace I mean what is opened with File > Open File... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues December 2014