November 2014 - jbosstools-issues

[JBoss JIRA] (JBIDE-18820) define how to handle ide.properties and avoid parent pom to always change

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18820?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-18820: --------------------------------------------- [~nickboldt] none of this *requires* it to be in parent pom. Putting this blindly in parent pom makes it forced that *Everything* need to rebuild to get this info. This is why JBIDE-13452 happened, was it not ? The *missing step* here is that foundation was not upversioned/updated - something that would *need* to happen anyway for this to work. So putting it in parent pom changes nothing if foundation plugin is not updated and version bumped. As you say your self it does not matter that the version is in the parent pom if the foundation plugin is not rebuilt, but the version of the plugin also need to change. Hence the version should just stay near it instead of bubble up as a global value that is listed as something you can rely on in other modules ...which you cannot or rather should not since it is *not* guaranteed to be right unless we are doing a full complete rebuild of *everything*. [~mickael_istria] I and [~fbricon] did consider adding a jboss tools branding plugin like we have for jbds but A) how do we ensure that is included AND activated when foundation loads its settings ?! B) how do we ensure it is *NOT* active when devstudio is running ? It is a *false* assumption that just because foundation has a bug fix that it needs to trigger a full rebuild of everything - this is the thing we need to stop depending on. If this is the case then none of this would be an issue. > define how to handle ide.properties and avoid parent pom to always change > ------------------------------------------------------------------------- > > Key: JBIDE-18820 > URL: https://issues.jboss.org/browse/JBIDE-18820 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Reporter: Max Rydahl Andersen > > As illustrated in JBIDE-18806 our current setup of how ide.properties and project versioning are not working or at least we seem to not get it updated right. > Current workaround applied is that parent pom now again defines the global version even though this is not reliable at all since not all plugins will be rebuilt. (see JBIDE-13452 for earlier attempts on this) > Opening this jira to make sure we walkthrough and write down which values should be in ide.properties and what level (4.2.0.CR1, 4.2.0 or 4.2. etc), when they get updated (hopefully rarely) and how to avoid parent pom from always having to respin because of a maintanence release. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18705) Application wizard, Embed wizard: Cartridge details are black in Win8

by Marián Labuda (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18705?page=com.atlassian.jira.plugi... ] Marián Labuda closed JBIDE-18705. --------------------------------- Verified in JBDS 8.0.1.CR1 build ID B333 on Windows 8.1. > Application wizard, Embed wizard: Cartridge details are black in Win8 > --------------------------------------------------------------------- > > Key: JBIDE-18705 > URL: https://issues.jboss.org/browse/JBIDE-18705 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.2.0.Final > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Labels: application_wizard > Fix For: 4.2.1.CR1 > > Attachments: application-wizard-black-details.png, application-wizard-fixed-details.png, embed-cartridges-black-details.png, embed-cartridges-fixed-details.png > > > The details group which shows the details for the selected cartridge or quickstart are black in win8: > !application-wizard-black-details.png! > !embed-cartridges-black-details.png! -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBDS-2912) OpenShift tooling is great but has some quirks and known usability issues

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBDS-2912?page=com.atlassian.jira.plugin.... ] Andre Dietisheim updated JBDS-2912: ----------------------------------- Fix Version/s: 8.0.0.GA > OpenShift tooling is great but has some quirks and known usability issues > -------------------------------------------------------------------------- > > Key: JBDS-2912 > URL: https://issues.jboss.org/browse/JBDS-2912 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Epic > Components: openshift > Reporter: Max Rydahl Andersen > Assignee: Andre Dietisheim > Fix For: 8.0.0.GA > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18008) Nested jars prevent SonarQube/FindBugs from running

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18008?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-18008: ---------------------------------------- Thanks for the note (and the fix). I'm trying this immediately. > Nested jars prevent SonarQube/FindBugs from running > --------------------------------------------------- > > Key: JBIDE-18008 > URL: https://issues.jboss.org/browse/JBIDE-18008 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: archives > Reporter: Mickael Istria > Assignee: Mickael Istria > Priority: Minor > Fix For: 4.3.x > > > Bundle org.jboss.ide.eclipse.archives.core makes SonarQube analysis fail because it's classes get included in some nested jar (and get to different location that target/classes). > Cf https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... > {code} > [ERROR] Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.4:sonar (default-cli) on project server.all: Can not execute SonarQube analysis: Can not execute Findbugs: Findbugs needs sources to be compiled. Please build project before executing sonar and check the location of compiled classes. -> [Help 1] > {code} > This is an exploded bundles with nested jars, we should investigate whether it's possible to turn it into a more standard jar, which would still be usable in its Ant version. Cf ./archives/tests/org.jboss.ide.eclipse.archives.test/inputs/projects/SimpleAntTest > Also, the jvmmonitor bundles use nested jars. We should avoid that too. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18008) Nested jars prevent SonarQube/FindBugs from running

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18008?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-18008: ------------------------------------- I believe this is fixed in master. I encourage you to revisit whether sonarqube works now on archives. > Nested jars prevent SonarQube/FindBugs from running > --------------------------------------------------- > > Key: JBIDE-18008 > URL: https://issues.jboss.org/browse/JBIDE-18008 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: archives > Reporter: Mickael Istria > Assignee: Mickael Istria > Priority: Minor > Fix For: 4.3.x > > > Bundle org.jboss.ide.eclipse.archives.core makes SonarQube analysis fail because it's classes get included in some nested jar (and get to different location that target/classes). > Cf https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... > {code} > [ERROR] Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.4:sonar (default-cli) on project server.all: Can not execute SonarQube analysis: Can not execute Findbugs: Findbugs needs sources to be compiled. Please build project before executing sonar and check the location of compiled classes. -> [Help 1] > {code} > This is an exploded bundles with nested jars, we should investigate whether it's possible to turn it into a more standard jar, which would still be usable in its Ant version. Cf ./archives/tests/org.jboss.ide.eclipse.archives.test/inputs/projects/SimpleAntTest > Also, the jvmmonitor bundles use nested jars. We should avoid that too. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18794) Move shared properties related to JRE paths and itest.skip into parent pom

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18794?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-18794: ------------------------------------- +1 - please squash. Good comments in the pom.xml, clear what to do next (ie, have your jenkins job pass in the jre props) > Move shared properties related to JRE paths and itest.skip into parent pom > -------------------------------------------------------------------------- > > Key: JBIDE-18794 > URL: https://issues.jboss.org/browse/JBIDE-18794 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: build, server > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > Some properties (and maybe the -Pitest profile) in the root of jbosstools-server can eventually be moved into the parent pom for reuse by other projects. > (This was suggested by Max to Rob at some point on 2014/11/20.) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18794) Move shared properties related to JRE paths and itest.skip into parent pom

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18794?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-18794: ---------------------------------------- +1 for this PR, and I agree that skipITests should be false by default (a good convention is that skipWhatever should be false by default). > Move shared properties related to JRE paths and itest.skip into parent pom > -------------------------------------------------------------------------- > > Key: JBIDE-18794 > URL: https://issues.jboss.org/browse/JBIDE-18794 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: build, server > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > Some properties (and maybe the -Pitest profile) in the root of jbosstools-server can eventually be moved into the parent pom for reuse by other projects. > (This was suggested by Max to Rob at some point on 2014/11/20.) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18820) define how to handle ide.properties and avoid parent pom to always change

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18820?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-18820: ---------------------------------------- {code}So either we hardcode it in a Foundation plugin (where it was) and a JBDS plugin (where it was) and risk forgetting to update it with every milestone release, or we move it into the parent pom and make it less likely that it's forgotten. {code} At least, the JBDS part should be in JBDS main pom. Mixing JBDS into JBT is really a bad design, and we need to keep the design clean, even if we sometimes forget an update (that we actually spotted fast enough to not consider it as a big risk). About where to put the jbosstools-version, I don't think it should be in Foundation, because Foundation is something that is not expected to be rebuilt for every JBoss Tools release. Maybe we should have a JBoss Tools branding plugin, which would be maintained downstream of all components, similarly to aggregator, and that we'd rebuild for every milestone.. > define how to handle ide.properties and avoid parent pom to always change > ------------------------------------------------------------------------- > > Key: JBIDE-18820 > URL: https://issues.jboss.org/browse/JBIDE-18820 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Reporter: Max Rydahl Andersen > > As illustrated in JBIDE-18806 our current setup of how ide.properties and project versioning are not working or at least we seem to not get it updated right. > Current workaround applied is that parent pom now again defines the global version even though this is not reliable at all since not all plugins will be rebuilt. (see JBIDE-13452 for earlier attempts on this) > Opening this jira to make sure we walkthrough and write down which values should be in ide.properties and what level (4.2.0.CR1, 4.2.0 or 4.2. etc), when they get updated (hopefully rarely) and how to avoid parent pom from always having to respin because of a maintanence release. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18818) Test timeout in org.jboss.tools.jsf.verification.test

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18818?page=com.atlassian.jira.plugi... ] Alexey Kazakov commented on JBIDE-18818: ---------------------------------------- [~nickboldt], the list of such tests is too long. The problem is not in particular tests but rather in the approach we use in our tests. We need to continue to investigate these problems and also we need to separate integration tests. Can Jenkins or whatever provide a stacktrace for JVM just before stop the build by timeout? It would be very helpful. > Test timeout in org.jboss.tools.jsf.verification.test > ----------------------------------------------------- > > Key: JBIDE-18818 > URL: https://issues.jboss.org/browse/JBIDE-18818 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jsf > Affects Versions: 4.2.1.CR1 > Reporter: Nick Boldt > Assignee: Alexey Kazakov > Priority: Blocker > Fix For: 4.2.1.Final > > > Tests that time out due to blocking UI or other thread lock result in builds that are recorded as ABORTED [0]. This isn't a problem in terms of publishing new content because the build runs quickly, publishes the new bits, and THEN starts running tests. > [0] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_4.... > But where it IS a problem is where we use a buildflow job to run the whole stack of JBT projects. Buildflows will also abort if they encounter an aborted job [1]. > [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-buildflow... > Why is this a problem? Because when we do a weekend spin (or respin) not all the projects in the stack are guaranteed to rebuild to verify all the downstream component tests all still work. > -- > If you cannot fix these tests so they run cleanly in Jenkins, please disable them or move them such that they can still be run LOCALLY using a profile, but will be skipped in Jenkins. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-290) enable jboss tools usage tracking for plugins installed directly

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-290?page=com.atlassian.jira.plugin.... ] Paul Leacu commented on JBTIS-290: ---------------------------------- https://github.com/jboss-switchyard/tools/pull/453 - SwitchYard PR. > enable jboss tools usage tracking for plugins installed directly > ---------------------------------------------------------------- > > Key: JBTIS-290 > URL: https://issues.jboss.org/browse/JBTIS-290 > Project: JBoss Tools Integration Stack > Issue Type: Feature Request > Reporter: Max Rydahl Andersen > Assignee: Paul Leacu > Priority: Critical > Attachments: settings.xml > > > I think it is time we get integration stack components stats to show up more consistently in stats (right now we only collect switchyard - we should do more) > There are two parts to it. > 1) add a line to https://github.com/jbosstools/jbosstools-base/blob/master/usage/plugins/o... for the key feature we want to count as "one install" > 2) add an *optional* dependency to your plugins to org.jboss.tools.usage - this ensures the statistics gathering happens no matter how the feature gets installed. > The following line should be added to plugins manifest.mf: > {code} > org.jboss.tools.usage;resolution:=optional;x-installation:=greedy > {code} > Example: https://github.com/jbosstools/jbosstools-server/blob/master/archives/plug... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 8 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 November 2014