February 2017 - jbosstools-issues

[JBoss JIRA] (JBIDE-23885) integration test: assert new element "Kind" and in all properties and changed structure in "Build" properties

by Andre Dietisheim (JIRA)

Andre Dietisheim created JBIDE-23885: ---------------------------------------- Summary: integration test: assert new element "Kind" and in all properties and changed structure in "Build" properties Key: JBIDE-23885 URL: https://issues.jboss.org/browse/JBIDE-23885 Project: Tools (JBoss Tools) Issue Type: Enhancement Components: integration-tests Affects Versions: 4.4.3.AM1 Reporter: Andre Dietisheim JBIDE-23841: In "Properties" we added a "Kind" property for all resources and changed the structure of the "Build" properties. The integration tests should assert these changes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-22776) Create integration tests PR check job for arquilian

by Josef Kopriva (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22776?page=com.atlassian.jira.plugi... ] Josef Kopriva closed JBIDE-22776. --------------------------------- Resolution: Done PR check job is fixed and working. Closing. > Create integration tests PR check job for arquilian > --------------------------------------------------- > > Key: JBIDE-22776 > URL: https://issues.jboss.org/browse/JBIDE-22776 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: build, qa > Reporter: Rastislav Wagner > Assignee: Josef Kopriva > Fix For: 4.4.x > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23817) Scaling: is not working with OpenShift 3.4 (CDK 2.4)

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23817?page=com.atlassian.jira.plugi... ] Jeff MAURY commented on JBIDE-23817: ------------------------------------ Wrote a simple Java program that mimic DevStudio use of the scale API. It appears that if the scale API is used on a ReplicationController managed by a DeploymentConfig then this fails with OCP 3.4 (this is the way DevStudio works). So we can fix it working on a DeploymentConfig if there is one > Scaling: is not working with OpenShift 3.4 (CDK 2.4) > ---------------------------------------------------- > > Key: JBIDE-23817 > URL: https://issues.jboss.org/browse/JBIDE-23817 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.3.AM2 > Environment: CDK 2.4 > Devstudio 10.3.0.AM2 > Reporter: Radim Hopp > Priority: Critical > Labels: openshift_v3 > Fix For: 4.4.3.Final > > Attachments: Spectacle.yJ3971.png > > > Scaling pods is broken when using Openshift 3.4 from CDK 2.4. I was not able to try it with another Openshift 3.4 installation (https://open.paas.redhat.com/ is not working properly from Devstudio either - ticket INC0496390 with service-now). > When I select scale to -> and select "4" to scale to 4 pods, the pods get started but they are immediately terminated and the scaling is "1" again. > This is not happening when I used https://console.engint.openshift.com/ (OpenShift v3.3.1.4). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23285) integration tests should share runtime downloads so that each test doesn't have to re-download the same runtime zips, and no longer use EOL'd runtimes

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23285?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-23285: --------------------------------------- [~nickboldt] I don't really know how you're using the shared folder today - have those files been copied there manually? Or does a build check the folder and if a thing is not present, it will download it first? If the latter, then you wouldn't need to migrate anything, right? Pavol raised a possible issue that when you share a download cache, jobs running simultaneously could try to write the same file at the same time - so I'm not sure how it was set up until now. > integration tests should share runtime downloads so that each test doesn't have to re-download the same runtime zips, and no longer use EOL'd runtimes > ------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: JBIDE-23285 > URL: https://issues.jboss.org/browse/JBIDE-23285 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: integration-tests > Affects Versions: 4.4.2.AM1 > Reporter: Nick Boldt > Assignee: Martin Malina > Fix For: 4.4.3.Final > > > While running the integration tests today to investigate JBDS-4077, I discovered that: > * org.jboss.ide.eclipse.as.ui.bot.test requires 11 runtimes, some of which are well past their EOL date [1]: > {code}jboss-3.2.8.SP1 jboss-4.2.3.GA jboss-5.1.0.GA jboss-as-7.0.2.Final wildfly-10.0.0.CR2 wildfly-9.0.1.Final > jboss-4.0.5.GA jboss-5.0.1.GA jboss-6.1.0.Final jboss-as-7.1.1.Final wildfly-8.2.0.Final{code} > * org.jboss.tools.deltaspike.ui.bot.test requires 1 runtime, wildfly-10.0.0.Final > [1] https://access.redhat.com/support/policy/updates/jboss_notes/eol vs. https://access.redhat.com/support/policy/updates/jboss_notes/ > So, three problems here: > a) different tests use different versions of the same runtime (WFLY 10.0.0.CR2 vs. Final) > b) different tests re-download their runtimes every time you do a clean, instead of fetching runtimes from a cache. So the same 160M of WFLY 10 gets downloaded twice. > c) we still test on runtimes that have been EOL'd years ago, such as AS 4.0 and earlier. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-20711) Changing deploy-name in component xml file will not take effect

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20711?page=com.atlassian.jira.plugi... ] Martin Malina edited comment on JBIDE-20711 at 2/8/17 3:29 AM: --------------------------------------------------------------- [~rob.stryker], please tell me how am I supposed to edit this file inside of Eclipse. When I browse the project, Eclipse will not show me the .settings folder at all. How is that a valid use case when afaics I cannot even open this file in Eclipse? was (Author: mmalina): [~rob.stryker], please tell me how am I supposed to edit this file inside of Eclipse. When I browse the project, Eclipse will not show me the .settings folder at all. > Changing deploy-name in component xml file will not take effect > --------------------------------------------------------------- > > Key: JBIDE-20711 > URL: https://issues.jboss.org/browse/JBIDE-20711 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server, upstream > Affects Versions: 4.3.0.CR1 > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.4.3.AM2 > > > Steps to replicate: > 1) Create a dynamic web project TestProject > 2) Create a server > 3) Add/Remove action in servers view. You will see the module name is TestProject > 4) Open the component.xml file in .settings folder and change deploy-name to some new value (RobsTest) > 5) Add/Remove, note module name didn't change > 6) Publish deployment, note its still deploying as TestProject > 7) Close project, then re-open it > 8) Add/Remove action, note the module now reads TestProject (RobsTest) (or similar) > 9) Publish, note module is deployed as RobsTest.war -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-20711) Changing deploy-name in component xml file will not take effect

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20711?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-20711: --------------------------------------- [~rob.stryker], please tell me how am I supposed to edit this file inside of Eclipse. When I browse the project, Eclipse will not show me the .settings folder at all. > Changing deploy-name in component xml file will not take effect > --------------------------------------------------------------- > > Key: JBIDE-20711 > URL: https://issues.jboss.org/browse/JBIDE-20711 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server, upstream > Affects Versions: 4.3.0.CR1 > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.4.3.AM2 > > > Steps to replicate: > 1) Create a dynamic web project TestProject > 2) Create a server > 3) Add/Remove action in servers view. You will see the module name is TestProject > 4) Open the component.xml file in .settings folder and change deploy-name to some new value (RobsTest) > 5) Add/Remove, note module name didn't change > 6) Publish deployment, note its still deploying as TestProject > 7) Close project, then re-open it > 8) Add/Remove action, note the module now reads TestProject (RobsTest) (or similar) > 9) Publish, note module is deployed as RobsTest.war -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23285) integration tests should share runtime downloads so that each test doesn't have to re-download the same runtime zips, and no longer use EOL'd runtimes

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23285?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-23285: ------------------------------------- These 3 look suspicious and I don't know why we'd use them. 10.x.zip eap6.zip eap7.zip > integration tests should share runtime downloads so that each test doesn't have to re-download the same runtime zips, and no longer use EOL'd runtimes > ------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: JBIDE-23285 > URL: https://issues.jboss.org/browse/JBIDE-23285 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: integration-tests > Affects Versions: 4.4.2.AM1 > Reporter: Nick Boldt > Assignee: Martin Malina > Fix For: 4.4.3.Final > > > While running the integration tests today to investigate JBDS-4077, I discovered that: > * org.jboss.ide.eclipse.as.ui.bot.test requires 11 runtimes, some of which are well past their EOL date [1]: > {code}jboss-3.2.8.SP1 jboss-4.2.3.GA jboss-5.1.0.GA jboss-as-7.0.2.Final wildfly-10.0.0.CR2 wildfly-9.0.1.Final > jboss-4.0.5.GA jboss-5.0.1.GA jboss-6.1.0.Final jboss-as-7.1.1.Final wildfly-8.2.0.Final{code} > * org.jboss.tools.deltaspike.ui.bot.test requires 1 runtime, wildfly-10.0.0.Final > [1] https://access.redhat.com/support/policy/updates/jboss_notes/eol vs. https://access.redhat.com/support/policy/updates/jboss_notes/ > So, three problems here: > a) different tests use different versions of the same runtime (WFLY 10.0.0.CR2 vs. Final) > b) different tests re-download their runtimes every time you do a clean, instead of fetching runtimes from a cache. So the same 160M of WFLY 10 gets downloaded twice. > c) we still test on runtimes that have been EOL'd years ago, such as AS 4.0 and earlier. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-22172) create automated install test for JBDS installer jar + all early access content in Central

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22172?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22172: ------------------------------- Sprint: devex #125 December 2016, devex #127 February 2017 (was: devex #125 December 2016, devex #126 January 2017) > create automated install test for JBDS installer jar + all early access content in Central > ------------------------------------------------------------------------------------------ > > Key: JBIDE-22172 > URL: https://issues.jboss.org/browse/JBIDE-22172 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build, install-tests > Affects Versions: 4.3.1.CR1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.3.AM2 > > > To better automate staging & release, we need a way to run a smoke test of a given installer jar, then to install all the GA & EA content in Central. > Steps to script: > a. wget installer jar > b. headless install (via -console or install.xml script) > c. install grinder or p2director install all the things in Central. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23652) coretests composite site not updated when publishing to /static and /stable

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23652?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-23652: ------------------------------- Sprint: devex #127 February 2017 (was: devex #126 January 2017) > coretests composite site not updated when publishing to /static and /stable > --------------------------------------------------------------------------- > > Key: JBIDE-23652 > URL: https://issues.jboss.org/browse/JBIDE-23652 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.2.Final > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Critical > Fix For: 4.4.3.AM2 > > > Realized the other day that the composite*.xml files in http://download.jboss.org/jbosstools/static/neon/stable/updates/coretests/ and http://download.jboss.org/jbosstools/neon/stable/updates/coretests/ were not updated after 4.4.0.Alpha1... and probably should be part of what's updated when we release to /development, /stable, /static, etc. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23643) wrap process for moving a .Final target platform into /static/ folder w/ a Jenkins job

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23643?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-23643: ------------------------------- Sprint: devex #125 December 2016, devex #127 February 2017 (was: devex #125 December 2016, devex #126 January 2017) > wrap process for moving a .Final target platform into /static/ folder w/ a Jenkins job > -------------------------------------------------------------------------------------- > > Key: JBIDE-23643 > URL: https://issues.jboss.org/browse/JBIDE-23643 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.3.AM1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.3.AM2 > > > When it's time to release the next set of .Final target platforms, the process ought to be run by a jenkins job rather than a local "copy this script into your console" operation. > See https://github.com/jbdevstudio/jbdevstudio-devdoc/blob/master/release_gui... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 February 2017