July 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-22717) Remove all server log view code

by Rob Stryker (JIRA)

Rob Stryker created JBIDE-22717: ----------------------------------- Summary: Remove all server log view code Key: JBIDE-22717 URL: https://issues.jboss.org/browse/JBIDE-22717 Project: Tools (JBoss Tools) Issue Type: Task Components: server Affects Versions: 4.5.0.AM1 Reporter: Rob Stryker Follow up on: https://issues.jboss.org/browse/JBIDE-22635 Remove the deprecated classes and extension points. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22717) Remove all server log view code

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22717?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-22717: -------------------------------- Affects Version/s: 4.4.0.Final (was: 4.5.0.AM1) > Remove all server log view code > ------------------------------- > > Key: JBIDE-22717 > URL: https://issues.jboss.org/browse/JBIDE-22717 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: server > Affects Versions: 4.4.0.Final > Reporter: Rob Stryker > > Follow up on: https://issues.jboss.org/browse/JBIDE-22635 > Remove the deprecated classes and extension points. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22635) Deprecate the Server Log View

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22635?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-22635: -------------------------------- Summary: Deprecate the Server Log View (was: Deprecate / Remove the Server Log View) > Deprecate the Server Log View > ----------------------------- > > Key: JBIDE-22635 > URL: https://issues.jboss.org/browse/JBIDE-22635 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Affects Versions: 4.4.1.AM1 > Reporter: Rob Stryker > Assignee: Rob Stryker > > Deprecate and remove the Server Log View. > The Server Log View was originally designed to allow a custom "Error Log" to be filled with information that wasn't just "errors" but more like tracing what the server adapter was doing. > In it's original form, it held all status warnings and errors, and users never saw them. Eventually, we started also sending the status objects to the official Error Log, so users may see them. Once that happened, the Server Log view became completely redundant. It's only benefits were that it occasionally over-logged stuff that wasn't appropriate to send to the main error log... but it's API / extension points were kinda ugly, and it overall isn't very useful any longer. > Also, other server adapters have requested we remove the action at least, for their server types, since they never use the Server Log. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22716) PR builder jobs don't log itests/, only tests/

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22716?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-22716: ---------------------------------------- There are no template at the moment. They have to be changed one by one (which is still not consuming too much time with this instance). > PR builder jobs don't log itests/, only tests/ > ---------------------------------------------- > > Key: JBIDE-22716 > URL: https://issues.jboss.org/browse/JBIDE-22716 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.AM2 > Reporter: Nick Boldt > Assignee: Mickael Istria > > Seems that the PR builds aren't collecting all the JUnit logs, because they only look for: > {code} > <testResults>tests/*/target/surefire-reports/*.xml,*/tests/*/target/surefire-reports/*.xml</testResults> > {code} > instead of > {code} > <testResults>*tests/*/target/surefire-reports/*.xml,*/*tests/*/target/surefire-reports/*.xml</testResults> > {code} > I've updated one job like this: > https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo... > Can the same change (adding * to tests/ => *tests/) be done easily for all the jobs? Where are the templates for these stored? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22694) Environment Var Wizard: Improve deletion of environment variables

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22694?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich edited comment on JBIDE-22694 at 7/11/16 2:53 PM: ------------------------------------------------------------------------ The table shows changes that user is going to submit. They are reversible. When user changes an entry, he can push 'Reset' and the old value is restored. When user pushes 'Delete' he still does not delete the entry permanently, it is only marked to be deleted when 'Finish' is finally pressed. So, if the 'deleted' item is hidden from the table, how it can be reset? Then, if user pushed 'Delete' by mistake, he will have only to close/reopen the dialog to prevent the unwanted change. But actually, it is worse - if the deleted item is not shown in the table, user may not notice that he pushed 'Delete' by mistake. So, consistency in the case when user is given the option to revert changes before he submits them is to be able to show all differences as it is done now. An alternative is to submit directly each change to server with no 'Reset' option, and 'Close' button instead of 'Finish'+'Cancel' - that is irreversible management. Compare it to GIT showing difference between stored state and local changed state. was (Author: scabanovich): The table shows changes that user is going to submit. They are reversible. When user changes an entry, he can push 'Reset' and the old value is restored. When user pushes 'Delete' he still does not delete the entry permanently, it is only marked to be deleted when OK is finally pressed. So, if the 'deleted' item is hidden from the table, how it can be reset? Then, if user pushed 'Delete' by mistake, he will have only to close/reopen the dialog to prevent the unwanted change. But actually, it is worse - if the deleted item is not shown in the table, user may not notice that he pushed 'Delete' by mistake. So, consistency in the case when user is given the option to revert changes before he submits them is to be able to show all differences as it is done now. An alternative is to submit directly each change to server with no 'Reset' option, and 'Close' button instead of 'OK'+'Cancel' - that is irreversible management. Compare it to GIT showing difference between stored state and local changed state. > Environment Var Wizard: Improve deletion of environment variables > ----------------------------------------------------------------- > > Key: JBIDE-22694 > URL: https://issues.jboss.org/browse/JBIDE-22694 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.1.AM1 > Reporter: Marián Labuda > Labels: env_var_wizard, openshift_v3 > > Deletion of environment variable does not match user expectation. If I delete an environment variable which has been added in earlier opened and closed Env. Var wizard, this variable has prefix [deleted]. I don't think this is good practice, we should be consistent across all wizards and dialog, so once user select an env var in table and push Delete button, value should be removed from the table. No labelling should be done here, the table should reflect real current state of environment variable (what it is gonna look like once I hit Finish button). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22694) Environment Var Wizard: Improve deletion of environment variables

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22694?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich edited comment on JBIDE-22694 at 7/11/16 2:51 PM: ------------------------------------------------------------------------ The table shows changes that user is going to submit. They are reversible. When user changes an entry, he can push 'Reset' and the old value is restored. When user pushes 'Delete' he still does not delete the entry permanently, it is only marked to be deleted when OK is finally pressed. So, if the 'deleted' item is hidden from the table, how it can be reset? Then, if user pushed 'Delete' by mistake, he will have only to close/reopen the dialog to prevent the unwanted change. But actually, it is worse - if the deleted item is not shown in the table, user may not notice that he pushed 'Delete' by mistake. So, consistency in the case when user is given the option to revert changes before he submits them is to be able to show all differences as it is done now. An alternative is to submit directly each change to server with no 'Reset' option, and 'Close' button instead of 'OK'+'Cancel' - that is irreversible management. Compare it to GIT showing difference between stored state and local changed state. was (Author: scabanovich): The table shows changes that user is going to submit. They are reversible. When user changes an entry, he can push 'Reset' and the old value is restored. When user pushes 'Delete' he still does not delete the entry permanently, it is only marked to be deleted when OK is finally pressed. So, if the 'deleted' item is hidden from the table, how it can be reset? Then, if user pushed 'Delete' by mistake, he will have only to close/reopen the dialog to prevent the unwanted change. But actually, it is worse - if the deleted item is not shown in the table, user may not notice that he pushed 'Delete' by mistake. So, consistency in the case when user is given the option to revert changes before he submits them is to be able to show all differences as it is done now. An alternative is to submit directly each change to server with no 'Reset' option. Compare it to GIT showing difference between stored state and local changed state. > Environment Var Wizard: Improve deletion of environment variables > ----------------------------------------------------------------- > > Key: JBIDE-22694 > URL: https://issues.jboss.org/browse/JBIDE-22694 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.1.AM1 > Reporter: Marián Labuda > Labels: env_var_wizard, openshift_v3 > > Deletion of environment variable does not match user expectation. If I delete an environment variable which has been added in earlier opened and closed Env. Var wizard, this variable has prefix [deleted]. I don't think this is good practice, we should be consistent across all wizards and dialog, so once user select an env var in table and push Delete button, value should be removed from the table. No labelling should be done here, the table should reflect real current state of environment variable (what it is gonna look like once I hit Finish button). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22694) Environment Var Wizard: Improve deletion of environment variables

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22694?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich edited comment on JBIDE-22694 at 7/11/16 2:49 PM: ------------------------------------------------------------------------ The table shows changes that user is going to submit. They are reversible. When user changes an entry, he can push 'Reset' and the old value is restored. When user pushes 'Delete' he still does not delete the entry permanently, it is only marked to be deleted when OK is finally pressed. So, if the 'deleted' item is hidden from the table, how it can be reset? Then, if user pushed 'Delete' by mistake, he will have only to close/reopen the dialog to prevent the unwanted change. But actually, it is worse - if the deleted item is not shown in the table, user may not notice that he pushed 'Delete' by mistake. So, consistency in the case when user is given the option to revert changes before he submits them is to be able to show all differences as it is done now. An alternative is to submit directly each change to server with no 'Reset' option. Compare it to GIT showing difference between stored state and local changed state. was (Author: scabanovich): The table shows changes that user is going to submit. They are reversible. When user changes an entry, he can push 'Reset' and the old value is restored. When user pushes 'Delete' he still does not delete the entry permanently, it is only marked to be deleted when OK is finally pressed. So, if the 'deleted' item is hidden from the table, how it can be reset? Then, if user pushed 'Delete' by mistake, he will have only to close/reopen the dialog to prevent the unwanted change. But actually, it is worse - if the deleted item is not shown in the table, user may not notice that he pushed 'Delete' by mistake. So, consistency in the case when user can revert changes before he submits them is to be able to show all differences as it is done now. An alternative is to submit directly each change to server with no 'Reset' option. Compare it to GIT showing difference between stored state and local changed state. > Environment Var Wizard: Improve deletion of environment variables > ----------------------------------------------------------------- > > Key: JBIDE-22694 > URL: https://issues.jboss.org/browse/JBIDE-22694 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.1.AM1 > Reporter: Marián Labuda > Labels: env_var_wizard, openshift_v3 > > Deletion of environment variable does not match user expectation. If I delete an environment variable which has been added in earlier opened and closed Env. Var wizard, this variable has prefix [deleted]. I don't think this is good practice, we should be consistent across all wizards and dialog, so once user select an env var in table and push Delete button, value should be removed from the table. No labelling should be done here, the table should reflect real current state of environment variable (what it is gonna look like once I hit Finish button). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22694) Environment Var Wizard: Improve deletion of environment variables

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22694?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich commented on JBIDE-22694: ----------------------------------------------- The table shows changes that user is going to submit. They are reversible. When user changes an entry, he can push 'Reset' and the old value is restored. When user pushes 'Delete' he still does not delete the entry permanently, it is only marked to be deleted when OK is finally pressed. So, if the 'deleted' item is hidden from the table, how it can be reset? Then, if user pushed 'Delete' by mistake, he will have only to close/reopen the dialog to prevent the unwanted change. But actually, it is worse - if the deleted item is not shown in the table, user may not notice that he pushed 'Delete' by mistake. So, consistency in the case when user can revert changes before he submits them is to be able to show all differences as it is done now. An alternative is to submit directly each change to server with no 'Reset' option. Compare it to GIT showing difference between stored state and local changed state. > Environment Var Wizard: Improve deletion of environment variables > ----------------------------------------------------------------- > > Key: JBIDE-22694 > URL: https://issues.jboss.org/browse/JBIDE-22694 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.1.AM1 > Reporter: Marián Labuda > Labels: env_var_wizard, openshift_v3 > > Deletion of environment variable does not match user expectation. If I delete an environment variable which has been added in earlier opened and closed Env. Var wizard, this variable has prefix [deleted]. I don't think this is good practice, we should be consistent across all wizards and dialog, so once user select an env var in table and push Delete button, value should be removed from the table. No labelling should be done here, the table should reflect real current state of environment variable (what it is gonna look like once I hit Finish button). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22678) Run integration-test and report results on incoming Pull Request

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22678?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-22678: ------------------------------------ Related: https://issues.jboss.org/browse/JBIDE-22716 > Run integration-test and report results on incoming Pull Request > ---------------------------------------------------------------- > > Key: JBIDE-22678 > URL: https://issues.jboss.org/browse/JBIDE-22678 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build, qa > Reporter: Mickael Istria > Assignee: Rastislav Wagner > Priority: Critical > > It would be interesting to have integraton-tests running on incoming Pull Requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22680) Create CI jobs running integration tests on incoming PRs

by Len DiMaggio (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22680?page=com.atlassian.jira.plugi... ] Len DiMaggio commented on JBIDE-22680: -------------------------------------- Yes - start with Rastislav - he has been leading our move to Central CI. > Create CI jobs running integration tests on incoming PRs > -------------------------------------------------------- > > Key: JBIDE-22680 > URL: https://issues.jboss.org/browse/JBIDE-22680 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: build, qa > Reporter: Mickael Istria > Fix For: 4.4.x > > > Once we have integration tests running against a given source (JBIDE-22679), let's create the CI jobs to run those automatically and vote on incoming pull requests. -- 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 July 2016