February 2017 - jbosstools-issues

[JBoss JIRA] (JBIDE-24001) Browsersim and Cordovasim are broken since jetty v 9.4.0 was added to TP

by Pavol Srna (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24001?page=com.atlassian.jira.plugi... ] Pavol Srna commented on JBIDE-24001: ------------------------------------ [~ibuziuk] I have PR's ready. Can you please review? Thx! > Browsersim and Cordovasim are broken since jetty v 9.4.0 was added to TP > ------------------------------------------------------------------------ > > Key: JBIDE-24001 > URL: https://issues.jboss.org/browse/JBIDE-24001 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: browsersim, cordovasim > Affects Versions: 4.5.0.AM1 > Reporter: Pavol Srna > Assignee: Ilya Buziuk > Fix For: 4.5.0.AM1 > > > There is a restriction in manifest: bundle-version="[9.3.9,9.4)", -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-24001) Browsersim and Cordovasim are broken since jetty v 9.4.0 was added to TP

by Pavol Srna (JIRA)

Pavol Srna created JBIDE-24001: ---------------------------------- Summary: Browsersim and Cordovasim are broken since jetty v 9.4.0 was added to TP Key: JBIDE-24001 URL: https://issues.jboss.org/browse/JBIDE-24001 Project: Tools (JBoss Tools) Issue Type: Bug Components: browsersim, cordovasim Affects Versions: 4.5.0.AM1 Reporter: Pavol Srna Fix For: 4.5.0.AM1 There is a restriction in manifest: bundle-version="[9.3.9,9.4)", -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBDS-4066) DevSuite Installer Account step styles are inconsistent with Target Folder step

by Jan Richter (JIRA)

[ https://issues.jboss.org/browse/JBDS-4066?page=com.atlassian.jira.plugin.... ] Jan Richter closed JBDS-4066. ----------------------------- Alright, now it looks as it should :) > DevSuite Installer Account step styles are inconsistent with Target Folder step > ------------------------------------------------------------------------------- > > Key: JBDS-4066 > URL: https://issues.jboss.org/browse/JBDS-4066 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Enhancement > Components: platform-installer > Affects Versions: 10.1.0.GA > Reporter: Denis Golovin > Assignee: Sudhir Verma > Labels: ui > Fix For: 10.3.0.GA > > Attachments: login.png, screenshot-1.png, screenshot-2.png > > > Account page looks different from Target Location page: > 1. Fields with invalid values have red glow border with gradient; > 2. There are three areas to show error messages one for each field and one for login error; > 3. Username and password error have styling different from login error and from validation messages on Target Location page; > 4. Field height is different from Target Location field; > 5. When validation messages appear they move elements on Account Page back and forth; > To Do: > 1. Always show only one message between fields and buttons > 2. If username and password are empty show error message: "Please enter your username and password" > 3. If username is empty show error message: "Please enter your username" > 4. If password is empty show error message: "Please enter your password" > 5. Show only one message at a time, if there is "Invalid account information, please try again" message and password or username is changed hide error message. > Account Step: > !screenshot-1.png! > Target Location Step: > !screenshot-2.png!: -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ERT-248) Improve UI for Docker reconnection use case [EBZ#495600]

by Jeff Johnston (JIRA)

[ https://issues.jboss.org/browse/ERT-248?page=com.atlassian.jira.plugin.sy... ] Jeff Johnston reassigned ERT-248: --------------------------------- Assignee: Jeff Johnston > Improve UI for Docker reconnection use case [EBZ#495600] > -------------------------------------------------------- > > Key: ERT-248 > URL: https://issues.jboss.org/browse/ERT-248 > Project: Eclipse Release Train > Issue Type: Task > Components: Linux Tools > Reporter: Friendly Jira Robot > Assignee: Jeff Johnston > Labels: Docker, bzira > > When a docker connection has been disabled, it's hard to make it work again. You need to click the Enable Connection button. This is not very user friendly. > Until today, I thought the connection was either active or inactive. But today I learnt it can also be disabled. In my opinion it's not practical to have a disabled state at all. > Let me describe the scenario I went through. I was using Container Development Kit which is a server adapter and once you start it, it will create a docker connection and connect to it - docker daemon is running inside CDK. But it would work the same way with a Docker Machine that you start, then stop, then start again. > 1. Start CDK (once started, it will create a docker connection) > 2. Docker connection is grey, but you can expand it. > 3. Expand docker connection in docker explorer - it works - you can see images > 4. Stop CDK > 5. Now the refresher job will timeout, so the docker connection will be disabled > 6. Start CDK again > Now I would expect to be able to work with the docker connection again like after the first start of CDK, but I can't, because now the connection has been disabled. So now I need to know that it's disabled and I need to enable it. I think it can be confusing for a lot of people - why do you need an additional step now? > The above steps could be reproduced with docker-machine. But instead of starting CDK, you would simply do "docker-machine start/stop default" from CLI. > I don't have an exact recipe on how this should be done. But I wonder if we need the disabled state at all. Because once a connection becomes inactive, it is no longer expanded, so it won't produce errors all the time. One issue is that if you had the Docker Images view opened at the same time, that one would probably keep trying to connect (if there was no such thing as a disabled docker connection). So I'm not sure how to solve this. > But the most important thing for me would be to make this use case (the steps above) more user friendly - i.e. make reconnection to a docker daemon a smoother experience. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ERT-248) Improve UI for Docker reconnection use case [EBZ#495600]

by Jeff Johnston (JIRA)

[ https://issues.jboss.org/browse/ERT-248?page=com.atlassian.jira.plugin.sy... ] Jeff Johnston updated ERT-248: ------------------------------ Sprint: devex #127 February 2017 > Improve UI for Docker reconnection use case [EBZ#495600] > -------------------------------------------------------- > > Key: ERT-248 > URL: https://issues.jboss.org/browse/ERT-248 > Project: Eclipse Release Train > Issue Type: Task > Components: Linux Tools > Reporter: Friendly Jira Robot > Assignee: Jeff Johnston > Labels: Docker, bzira > > When a docker connection has been disabled, it's hard to make it work again. You need to click the Enable Connection button. This is not very user friendly. > Until today, I thought the connection was either active or inactive. But today I learnt it can also be disabled. In my opinion it's not practical to have a disabled state at all. > Let me describe the scenario I went through. I was using Container Development Kit which is a server adapter and once you start it, it will create a docker connection and connect to it - docker daemon is running inside CDK. But it would work the same way with a Docker Machine that you start, then stop, then start again. > 1. Start CDK (once started, it will create a docker connection) > 2. Docker connection is grey, but you can expand it. > 3. Expand docker connection in docker explorer - it works - you can see images > 4. Stop CDK > 5. Now the refresher job will timeout, so the docker connection will be disabled > 6. Start CDK again > Now I would expect to be able to work with the docker connection again like after the first start of CDK, but I can't, because now the connection has been disabled. So now I need to know that it's disabled and I need to enable it. I think it can be confusing for a lot of people - why do you need an additional step now? > The above steps could be reproduced with docker-machine. But instead of starting CDK, you would simply do "docker-machine start/stop default" from CLI. > I don't have an exact recipe on how this should be done. But I wonder if we need the disabled state at all. Because once a connection becomes inactive, it is no longer expanded, so it won't produce errors all the time. One issue is that if you had the Docker Images view opened at the same time, that one would probably keep trying to connect (if there was no such thing as a disabled docker connection). So I'm not sure how to solve this. > But the most important thing for me would be to make this use case (the steps above) more user friendly - i.e. make reconnection to a docker daemon a smoother experience. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ERT-248) Improve UI for Docker reconnection use case [EBZ#495600]

by Jeff Johnston (JIRA)

[ https://issues.jboss.org/browse/ERT-248?page=com.atlassian.jira.plugin.sy... ] Jeff Johnston resolved ERT-248. ------------------------------- Fix Version/s: Neon.3 (4.6) Resolution: Done > Improve UI for Docker reconnection use case [EBZ#495600] > -------------------------------------------------------- > > Key: ERT-248 > URL: https://issues.jboss.org/browse/ERT-248 > Project: Eclipse Release Train > Issue Type: Task > Components: Linux Tools > Reporter: Friendly Jira Robot > Assignee: Jeff Johnston > Labels: Docker, bzira > Fix For: Neon.3 (4.6) > > > When a docker connection has been disabled, it's hard to make it work again. You need to click the Enable Connection button. This is not very user friendly. > Until today, I thought the connection was either active or inactive. But today I learnt it can also be disabled. In my opinion it's not practical to have a disabled state at all. > Let me describe the scenario I went through. I was using Container Development Kit which is a server adapter and once you start it, it will create a docker connection and connect to it - docker daemon is running inside CDK. But it would work the same way with a Docker Machine that you start, then stop, then start again. > 1. Start CDK (once started, it will create a docker connection) > 2. Docker connection is grey, but you can expand it. > 3. Expand docker connection in docker explorer - it works - you can see images > 4. Stop CDK > 5. Now the refresher job will timeout, so the docker connection will be disabled > 6. Start CDK again > Now I would expect to be able to work with the docker connection again like after the first start of CDK, but I can't, because now the connection has been disabled. So now I need to know that it's disabled and I need to enable it. I think it can be confusing for a lot of people - why do you need an additional step now? > The above steps could be reproduced with docker-machine. But instead of starting CDK, you would simply do "docker-machine start/stop default" from CLI. > I don't have an exact recipe on how this should be done. But I wonder if we need the disabled state at all. Because once a connection becomes inactive, it is no longer expanded, so it won't produce errors all the time. One issue is that if you had the Docker Images view opened at the same time, that one would probably keep trying to connect (if there was no such thing as a disabled docker connection). So I'm not sure how to solve this. > But the most important thing for me would be to make this use case (the steps above) more user friendly - i.e. make reconnection to a docker daemon a smoother experience. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBDS-4283) migrate devstudio_10.0.neon jobs to CCI

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-4283?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-4283: ----------------------------- Fix Version/s: 10.4.0.AM1 > migrate devstudio_10.0.neon jobs to CCI > --------------------------------------- > > Key: JBDS-4283 > URL: https://issues.jboss.org/browse/JBDS-4283 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Sub-task > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 10.4.0.AM1 > > > Migrate all jobs in this view to CCI: > https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/DevStudio/view/... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBDS-4284) migrate _master jobs to CCI

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-4284?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-4284: ----------------------------- Component/s: build > migrate _master jobs to CCI > --------------------------- > > Key: JBDS-4284 > URL: https://issues.jboss.org/browse/JBDS-4284 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Sub-task > Components: build > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 11.0.0.AM1 > > > Migrate all jobs in this view to CCI: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBDS-4284) migrate _master jobs to CCI

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-4284?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-4284: ----------------------------- Fix Version/s: 11.0.0.AM1 > migrate _master jobs to CCI > --------------------------- > > Key: JBDS-4284 > URL: https://issues.jboss.org/browse/JBDS-4284 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Sub-task > Reporter: Nick Boldt > Fix For: 11.0.0.AM1 > > > Migrate all jobs in this view to CCI: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBDS-4284) migrate _master jobs to CCI

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-4284?page=com.atlassian.jira.plugin.... ] Nick Boldt reassigned JBDS-4284: -------------------------------- Assignee: Nick Boldt > migrate _master jobs to CCI > --------------------------- > > Key: JBDS-4284 > URL: https://issues.jboss.org/browse/JBDS-4284 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Sub-task > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 11.0.0.AM1 > > > Migrate all jobs in this view to CCI: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... -- 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