November 2014 - jbosstools-issues

[JBoss JIRA] (JBIDE-18841) Add/Remove CDI support when facet version is changed

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18841?page=com.atlassian.jira.plugi... ] Alexey Kazakov reassigned JBIDE-18841: -------------------------------------- Assignee: Viacheslav Kabanovich > Add/Remove CDI support when facet version is changed > ---------------------------------------------------- > > Key: JBIDE-18841 > URL: https://issues.jboss.org/browse/JBIDE-18841 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: cdi > Affects Versions: 4.2.1.CR1 > Reporter: Rastislav Wagner > Assignee: Viacheslav Kabanovich > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > We should enable (and remove ?) CDI support when version of project facet is changed, not only when it is activated. > Ie changing web facet from 3.0 to 3.1 or ejb facet to 3.2 -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18836) Update TPs/requirements/installer with m2e-apt 1.1.1

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18836?page=com.atlassian.jira.plugi... ] Alexey Kazakov updated JBIDE-18836: ----------------------------------- Labels: respin-a (was: ) > Update TPs/requirements/installer with m2e-apt 1.1.1 > ---------------------------------------------------- > > Key: JBIDE-18836 > URL: https://issues.jboss.org/browse/JBIDE-18836 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.2.1.CR1 > Reporter: Fred Bricon > Assignee: Nick Boldt > Labels: respin-a > Fix For: 4.2.1.CR1 > > > m2e-apt 1.1.1 has been released. > It's available from http://download.jboss.org/jbosstools/updates/m2e-extensions/m2e-apt/1.1.1... > Can you add it to our TP/requirements/installer, pretty please? -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18836) Update TPs/requirements/installer with m2e-apt 1.1.1

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18836?page=com.atlassian.jira.plugi... ] Alexey Kazakov updated JBIDE-18836: ----------------------------------- Fix Version/s: 4.2.1.CR1 (was: 4.2.1.Final) > Update TPs/requirements/installer with m2e-apt 1.1.1 > ---------------------------------------------------- > > Key: JBIDE-18836 > URL: https://issues.jboss.org/browse/JBIDE-18836 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.2.1.CR1 > Reporter: Fred Bricon > Assignee: Nick Boldt > Fix For: 4.2.1.CR1 > > > m2e-apt 1.1.1 has been released. > It's available from http://download.jboss.org/jbosstools/updates/m2e-extensions/m2e-apt/1.1.1... > Can you add it to our TP/requirements/installer, pretty please? -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

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

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18820?page=com.atlassian.jira.plugi... ] Alexey Kazakov reassigned JBIDE-18820: -------------------------------------- Assignee: Nick Boldt > 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 > Assignee: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > 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, 4 months

1
0
0 / 0

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

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18820?page=com.atlassian.jira.plugi... ] Alexey Kazakov updated JBIDE-18820: ----------------------------------- Fix Version/s: 4.3.0.Alpha1 > 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 > Fix For: 4.3.0.Alpha1 > > > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13835) Improve publish script (split? Move to maven?)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13835?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-13835: ------------------------------------ We can hope, but we will be full of fail. We cannot put the EAP bundled installers on ds.rh.com. So we have two choices: a) publish everything BUT the EAP bundles (rsync with --exclude) b) publish only the update sites, and leave all the builds/ on www.qa But there's no way the publish script can do the same for JBT and JBDS. At least we can make the URL patterns more consistent. > Improve publish script (split? Move to maven?) > ---------------------------------------------- > > Key: JBIDE-13835 > URL: https://issues.jboss.org/browse/JBIDE-13835 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Reporter: Mickael Istria > Fix For: 4.1.x, 4.2.x > > > Publish script deals with a lot of different and not-always-related things. It makes it difficult to maintain it. We should think about some improvements such as > * different conventions from different stream > * components vs aggregate > * devstudio vs jbosstools. > Or, > * Make publishing part of a "mvn deploy" step. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18460) 'Add type to deployment' quickfix doesn't work with abstract classes

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18460?page=com.atlassian.jira.plugi... ] Snjezana Peco updated JBIDE-18460: ---------------------------------- Fix Version/s: (was: 4.2.1.Final) > 'Add type to deployment' quickfix doesn't work with abstract classes > -------------------------------------------------------------------- > > Key: JBIDE-18460 > URL: https://issues.jboss.org/browse/JBIDE-18460 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: testing-tools > Affects Versions: 4.2.0.CR1 > Reporter: Snjezana Peco > Assignee: Snjezana Peco > Fix For: 4.3.0.Alpha1 > > > Steps to reproduce: > - create an abstract Arquillian JUnit test with a deployment method > - create an Arquillian JUnit test extending the previous created abstract class > - add a type not included in the deployment method to the test created in the step 2 > The "Type is not included in any deployment" marker will be created properly > - call the "Add type to deployment" quickfix > You will get the "Cannot find a deployment method" dialog. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18460) 'Add type to deployment' quickfix doesn't work with abstract classes

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18460?page=com.atlassian.jira.plugi... ] Snjezana Peco reassigned JBIDE-18460: ------------------------------------- Assignee: Snjezana Peco > 'Add type to deployment' quickfix doesn't work with abstract classes > -------------------------------------------------------------------- > > Key: JBIDE-18460 > URL: https://issues.jboss.org/browse/JBIDE-18460 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: testing-tools > Affects Versions: 4.2.0.CR1 > Reporter: Snjezana Peco > Assignee: Snjezana Peco > Fix For: 4.2.1.Final, 4.3.0.Alpha1 > > > Steps to reproduce: > - create an abstract Arquillian JUnit test with a deployment method > - create an Arquillian JUnit test extending the previous created abstract class > - add a type not included in the deployment method to the test created in the step 2 > The "Type is not included in any deployment" marker will be created properly > - call the "Add type to deployment" quickfix > You will get the "Cannot find a deployment method" dialog. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

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

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18818?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-18818 at 11/27/14 6:52 PM: -------------------------------------------------------------- D'oh! Forgot about those. In fact it's easier to browse from the job's individual build page [1] than to dig into the Build Artifacts folder [2]. Screenshot: http://snag.gy/OfGaB.jpg [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_4.... [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_4.... was (Author: nickboldt): D'oh! Forgot about those. In fact it's easier to browse from the job's individual build page [1] than to dig into the Build Artifacts folder [2]. [^http://snag.gy/OfGaB.jpg] [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_4.... [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_4.... > 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, 4 months

1
0
0 / 0

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

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18818?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-18818: ------------------------------------ D'oh! Forgot about those. In fact it's easier to browse from the job's individual build page [1] than to dig into the Build Artifacts folder [2]. [^http://snag.gy/OfGaB.jpg] [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_4.... [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_4.... > 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, 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 November 2014