June 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBTIS-671) Teiid smoke tests are failing on fenix

by Matus Makovy (JIRA)

[ https://issues.jboss.org/browse/JBTIS-671?page=com.atlassian.jira.plugin.... ] Matus Makovy resolved JBTIS-671. -------------------------------- Resolution: Done I've done some updates in https://github.com/mmakovy/jbosstools-integration-stack-tests/commit/99a0.... I've run the test multiple times on fenix and it succeeded. > Teiid smoke tests are failing on fenix > -------------------------------------- > > Key: JBTIS-671 > URL: https://issues.jboss.org/browse/JBTIS-671 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: QE, teiid > Affects Versions: 4.0.0 > Reporter: Andrej Podhradsky > Assignee: Matus Makovy > > Stacktrace > {code} > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at org.jboss.tools.teiid.ui.bot.test.ModelWizardTest.xsdDatatypeModel(ModelWizardTest.java:99) > {code} > and > Error Message > The following shells remained open [New Model Wizard] > Stacktrace > {code} > java.lang.AssertionError: The following shells remained open [New Model Wizard] > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.reddeer.junit.extension.after.test.impl.CloseAllShellsExt.run(CloseAllShellsExt.java:68) > at org.jboss.reddeer.junit.extension.after.test.impl.CloseAllShellsExt.runAfterTest(CloseAllShellsExt.java:60) > at org.jboss.reddeer.junit.internal.runner.statement.RunIAfterTestExtensions.evaluate(RunIAfterTestExtensions.java:64) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.jboss.reddeer.junit.internal.runner.RequirementsRunner.runChild(RequirementsRunner.java:165) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.jboss.reddeer.junit.internal.runner.statement.RunBefores.evaluate(RunBefores.java:69) > at org.jboss.reddeer.junit.internal.runner.statement.FulfillRequirementsStatement.evaluate(FulfillRequirementsStatement.java:35) > at org.jboss.reddeer.junit.internal.runner.statement.RunIBeforeClassExtensions.evaluate(RunIBeforeClassExtensions.java:60) > at org.jboss.reddeer.junit.internal.runner.statement.RunAfters.evaluate(RunAfters.java:58) > at org.jboss.reddeer.junit.internal.runner.statement.CleanUpRequirementStatement.evaluate(CleanUpRequirementStatement.java:34) > at org.jboss.reddeer.junit.internal.runner.statement.RunIAfterClassExtensions.evaluate(RunIAfterClassExtensions.java:48) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.jboss.reddeer.junit.internal.runner.RequirementsRunner.run(RequirementsRunner.java:146) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:156) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:82) > at org.eclipse.tycho.surefire.osgibooter.OsgiSurefireBooter.run(OsgiSurefireBooter.java:91) > at org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication.runTests(AbstractUITestApplication.java:44) > at org.eclipse.e4.ui.internal.workbench.swt.E4Testable$1.run(E4Testable.java:73) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ERT-204) Docker Machine lookup does not work on Windows machines [EBZ#494305]

by Xavier Coulon (JIRA)

[ https://issues.jboss.org/browse/ERT-204?page=com.atlassian.jira.plugin.sy... ] Xavier Coulon updated ERT-204: ------------------------------ Issue Type: Bug (was: Task) > Docker Machine lookup does not work on Windows machines [EBZ#494305] > -------------------------------------------------------------------- > > Key: ERT-204 > URL: https://issues.jboss.org/browse/ERT-204 > Project: Eclipse Release Train > Issue Type: Bug > Components: Linux Tools > Reporter: Friendly Jira Robot > Assignee: Xavier Coulon > Labels: 5.0.0, Docker, bzira > Fix For: Neon (4.6) > > > When creating Docker connection, the docker-machine mechanism does not work on Window as it seems to find docker-machine and not docker-machine.exe -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22664) Invalid registry URL when OS3 connection created by CDK server

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22664?page=com.atlassian.jira.plugi... ] Jeff MAURY commented on JBIDE-22664: ------------------------------------ This is related to the VAGRANT_NO_COLOR flag.It must be set otherwise garbage escape characters will be added to the output. But seems --no-color don't work with service-manager > Invalid registry URL when OS3 connection created by CDK server > -------------------------------------------------------------- > > Key: JBIDE-22664 > URL: https://issues.jboss.org/browse/JBIDE-22664 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.0.Final > Reporter: Jeff MAURY > Assignee: Rob Stryker > Priority: Critical > Fix For: 4.4.1.M2 > > Attachments: screenshot-1.png > > > When the OS3 connection is created when launching the CDK server, then the Docker registry URL is not valid (garbage characters at the end). This may be a Windows problem. The CDK version used what CDK 2.1RC5 (see [^screenshot-1.png]) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-12337) json_string formatter recognized as invalid syntax

by Ondrej Dockal (JIRA)

[ https://issues.jboss.org/browse/JBIDE-12337?page=com.atlassian.jira.plugi... ] Ondrej Dockal closed JBIDE-12337. --------------------------------- Verified on devstudio: Version: 10.0.0.GA Build id: GA-v20160615-1853-B33 > json_string formatter recognized as invalid syntax > -------------------------------------------------- > > Key: JBIDE-12337 > URL: https://issues.jboss.org/browse/JBIDE-12337 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: freemarker > Affects Versions: 3.3.0.Final > Environment: Eclipse Juno > Reporter: Ljudevit Hab > Assignee: Max Rydahl Andersen > Priority: Minor > Fix For: 4.4.0.Final > > > ?json_string formatter is not recognized as valid syntax: > for example: > email: "${user.email?json_string}" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-22619: --------------------------------------------- And I just want to repeat that nothing really changed in what we do about API readyness so lets please not get confused about "we are not doing waterfall" or "we are now doing agile". We never did waterfall, nor are we currently doing GA level agile sprint builds. That is a separate issue and IMO much bigger improvement and change to do. > Decide strategy for fixversion targets in JIRA > ---------------------------------------------- > > Key: JBIDE-22619 > URL: https://issues.jboss.org/browse/JBIDE-22619 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.4.1.M1 > Reporter: Nick Boldt > Assignee: Alexey Kazakov > Fix For: 4.4.1.M1 > > > We need to decide the strategy for milestones / fixversions in JIRA. > One suggestion has been to align fixversions w/ sprint numbers, thus: > * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...? > instead of > * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ? > Questions/concerns: > * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies? > * whatever schema we adopt has to work with bzira and jiralint > * any other systems that parse JIRA for integration purposes? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen edited comment on JBIDE-22619 at 6/28/16 5:56 AM: ---------------------------------------------------------------------- This problem is not unique for M* also applies for S* - but I thought the use of jgit timestamps included removing the qualifier so I hadn't considered this. This was btw. *one* of the reasons we moved away from M* to using alpha/beta etc. now that I remember it I think B is a nogo - GA and Final is the general recognized way to write it. In A, DM and EM don't work either if we need to do CR's, so AM1, AM2, ... would work since its clearly not just an A or Alpha. was (Author: maxandersen): This problem is not unique for M* also applies for S* - but I thought the use of jgit timestamps included removing the qualifier so I hadn't considered this. This was btw. *one* of the reasons we moved away from M* to using alpha/beta etc. now that I remember it I think B is a nogo - GA and Final is the general recognized way to write it. In A, DM and EM don't work either if we need to do CR's, so AM would work, or just A1,A2, ....? > Decide strategy for fixversion targets in JIRA > ---------------------------------------------- > > Key: JBIDE-22619 > URL: https://issues.jboss.org/browse/JBIDE-22619 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.4.1.M1 > Reporter: Nick Boldt > Assignee: Alexey Kazakov > Fix For: 4.4.1.M1 > > > We need to decide the strategy for milestones / fixversions in JIRA. > One suggestion has been to align fixversions w/ sprint numbers, thus: > * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...? > instead of > * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ? > Questions/concerns: > * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies? > * whatever schema we adopt has to work with bzira and jiralint > * any other systems that parse JIRA for integration purposes? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-22619: --------------------------------------------- This problem is not unique for M* also applies for S* - but I thought the use of jgit timestamps included removing the qualifier so I hadn't considered this. This was btw. *one* of the reasons we moved away from M* to using alpha/beta etc. now that I remember it I think B is a nogo - GA and Final is the general recognized way to write it. In A, DM and EM don't work either if we need to do CR's, so AM would work, or just A1,A2, ....? > Decide strategy for fixversion targets in JIRA > ---------------------------------------------- > > Key: JBIDE-22619 > URL: https://issues.jboss.org/browse/JBIDE-22619 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.4.1.M1 > Reporter: Nick Boldt > Assignee: Alexey Kazakov > Fix For: 4.4.1.M1 > > > We need to decide the strategy for milestones / fixversions in JIRA. > One suggestion has been to align fixversions w/ sprint numbers, thus: > * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...? > instead of > * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ? > Questions/concerns: > * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies? > * whatever schema we adopt has to work with bzira and jiralint > * any other systems that parse JIRA for integration purposes? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22639) Opening an Openshift3 server adapter when connection does not exists anymore causes NPE

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22639?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22639: ------------------------------------- Attachment: non-existent-workspace-reference.png > Opening an Openshift3 server adapter when connection does not exists anymore causes NPE > --------------------------------------------------------------------------------------- > > Key: JBIDE-22639 > URL: https://issues.jboss.org/browse/JBIDE-22639 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift, server > Affects Versions: 4.4.0.Final > Reporter: Jeff MAURY > Fix For: 4.4.1.M2 > > Attachments: non-existent-workspace-reference.png, screenshot-1.png > > > ASSERT: create an Openshift3 connection > ASSERT: create a server adapter from that connection > ASSERT: delete the Openshift3 connection > EXEC: open the server adapter > ASSERT: NPE is thrown and dialog is displayed (see [^screenshot-1.png]) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22639) Opening an Openshift3 server adapter when connection does not exists anymore causes NPE

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22639?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-22639: ------------------------------------------ [#1237|https://github.com/jbosstools/jbosstools-openshift/pull/1237] applied the error that comes up now complains about the workspace project in a way that's not user-friendly: !non-existent-workspace-reference.png! > Opening an Openshift3 server adapter when connection does not exists anymore causes NPE > --------------------------------------------------------------------------------------- > > Key: JBIDE-22639 > URL: https://issues.jboss.org/browse/JBIDE-22639 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift, server > Affects Versions: 4.4.0.Final > Reporter: Jeff MAURY > Fix For: 4.4.1.M2 > > Attachments: screenshot-1.png > > > ASSERT: create an Openshift3 connection > ASSERT: create a server adapter from that connection > ASSERT: delete the Openshift3 connection > EXEC: open the server adapter > ASSERT: NPE is thrown and dialog is displayed (see [^screenshot-1.png]) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22639) Opening an Openshift3 server adapter when connection does not exists anymore causes NPE

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22639?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-22639: ------------------------------------------ [~jeffmaury] +1 > Opening an Openshift3 server adapter when connection does not exists anymore causes NPE > --------------------------------------------------------------------------------------- > > Key: JBIDE-22639 > URL: https://issues.jboss.org/browse/JBIDE-22639 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift, server > Affects Versions: 4.4.0.Final > Reporter: Jeff MAURY > Fix For: 4.4.1.M2 > > Attachments: screenshot-1.png > > > ASSERT: create an Openshift3 connection > ASSERT: create a server adapter from that connection > ASSERT: delete the Openshift3 connection > EXEC: open the server adapter > ASSERT: NPE is thrown and dialog is displayed (see [^screenshot-1.png]) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 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 June 2016