February 2017 - jbosstools-issues

[JBoss JIRA] (JBIDE-23678) remediation required installing jbosstools 4.4.3.AM1 on Neon.2

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23678?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-23678: ------------------------------- Fix Version/s: 4.4.4.AM1 (was: 4.4.3.AM2) > remediation required installing jbosstools 4.4.3.AM1 on Neon.2 > -------------------------------------------------------------- > > Key: JBIDE-23678 > URL: https://issues.jboss.org/browse/JBIDE-23678 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, target-platform > Affects Versions: 4.4.3.AM1 > Reporter: Nick Boldt > Assignee: Victor Rubezhny > Fix For: 4.4.4.AM1 > > Attachments: remediation-required-jbt443am1.png, remediation-required-jbt443am1_skip_items.png, remediation-required-jbt443am1_upgrades.png > > > Remediation required for installing jbosstools 4.4.3.AM1 -- seems we have newer versions of JSON/JSDT plugins in our target platform than are in Neon.2. > Install manifest contains: > * org.eclipse.wst.jsdt.feature 2.0.0 (4 versions), > * 1.6.201 (2 versions), and > * 2.0.200 (1 version) - *total 7 references*! > Also, org.eclipse.wst.web_ui.feature.feature.group depends on org.eclipse.wst.jsdt.feature.feature.group, which pulls in another ref/requirement. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-20529) Master JIRA for XML Validation Problems

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20529?page=com.atlassian.jira.plugi... ] Nick Boldt reassigned JBIDE-20529: ---------------------------------- Assignee: Rob Stryker > Master JIRA for XML Validation Problems > --------------------------------------- > > Key: JBIDE-20529 > URL: https://issues.jboss.org/browse/JBIDE-20529 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: project-examples, server > Reporter: Rob Stryker > Assignee: Rob Stryker > Labels: xtriage > Fix For: 4.4.3.Final > > > This JIRA is meant to be a master container jira for all xml validation issues. These include identifying projects that are enganging in bad xml behavior, projects that point to namespaces or xsd locations that no longer exist, example projects using relative paths for linking to other xsd, and others. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23783) Server adapter editor: Project settings composite is badly layouted

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23783?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-23783: ------------------------------- Fix Version/s: 4.4.4.AM1 (was: 4.4.3.AM2) > Server adapter editor: Project settings composite is badly layouted > ------------------------------------------------------------------- > > Key: JBIDE-23783 > URL: https://issues.jboss.org/browse/JBIDE-23783 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.3.AM1 > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Labels: openshift_v3, server_adapter_editor > Fix For: 4.4.4.AM1 > > Attachments: adapter.png, corrected-project-settings-composite.png, project-settings-composite.png, resized-project-settings-composite.png > > > steps to reproduce: > # ASSERT: make sure that you have a server adapter defined > # EXEC: open up the editor for your server adapter > Result: > The project settings composite is badly layouted, especially the right border boundaries are not even: > !project-settings-composite.png! > # EXEC: maximise the editor > Result: > The "Eclipse Project:" combo does not fill all the available space. At times you also see this combo jumping in horizontal size. At times it's even smearing across redraws, there are leftovers of prior sizes. > !resized-project-settings-composite.png! -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-19182) Incremental Publish after Full Publish WRT dodeploy markers

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19182?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-19182: ------------------------------- Fix Version/s: 4.4.3.Final (was: 4.4.3.AM2) > Incremental Publish after Full Publish WRT dodeploy markers > ----------------------------------------------------------- > > Key: JBIDE-19182 > URL: https://issues.jboss.org/browse/JBIDE-19182 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.2.0.Final > Reporter: Rob Stryker > Fix For: 4.4.3.Final > > > THis issue is opened in regards to comments by [~dlmiles] on https://issues.jboss.org/browse/JBIDE-18862 > I am saying you should block all 'deployment directory' file modifications when you know the AS is busy using the 'deployment directory' to "deploy" (a.k.a. starting) or "undeploy" (a.k.a. stopping) of a module (or the AS itself is starting/stopping in certain scenarios). Ideally you use a file watcher API when available so there is no busy/wait loop adding additional milliseconds of delays because the wait part is never instant. > But in an example scenario where you perform a Full Publish then 2 additional Incremental Publish ops immediately after, there is no reason to block the incrementals if you know the AS has not picked up the original Full Publish yet. You can effectively merge those two incrementals into the full publish operation behind the back of the AS. > But you are presented with a race scenario, you have already laid down the *.dodeploy at the end of the original Full Publish. So Eclipse needs to effectively notice that scenario exists, revoke and remember that instruction to the AS in an atomic way (what I mean by this is Eclipse knows for sure if it cancelled it in time, or if it was too late and the AS got to the full publish first and started deploying). > You need to do this so Eclipse can make file change modifications to the 'deployment directory' again. > Once Eclipse has completed the file change operations, if takes that remembered state and puts back the *.dodeploy file (even though this is an Incremental Publish operation). You can think of this like a "save state" and "restore state" pattern if that helps. Or you can think of this like the Eclipse target goal state for the AS (such as "AS:started" and "module.abc:started") is compared to the actual AS state (such as "AS: started" and "module.abc:stopped"), and Eclipse then brings them into alignment to do this it realizes it needs to lay down the *.dodeploy marker file (even though this is an incremental publish). > I think with the current marker file arrangements there maybe a tiny window of time where Eclipse IDE will get things wrong in respect of the AS ? But maybe ensuring both Eclipse IDE and the AS check the return value of the file delete for *.dodeploy whomever was successful in deleting the file wins, whichever party got the error "No Such File" loses and performs a rollback/cleanup of the situation to ensure it tries again soon. > So you can speak for the JBIDE side but can someone check the AS side ? File#delete(new File("foobar.dodeploy")) != true. The AS has to delete the command instruction file before it starts to process that command, but after it has laid down a state change file (*.isdeploying). > One of the goals of the marker files is that at no point in time is there a snapshot of the files that exist in the directory; that would leave an observer to interpret the wrong state. For example deleting one marker file before laying down the next would be bad, because there is a snapshot of time when no state marker file exists in the directory, leaving the observer to interpret that nothing is happening with that module. The alternative is to lay both the new file first then delete the old one, now there is a window of time when 2 marker files indicate state for 1 module, this is good and valid since the observer can clearly see the correct state. > So if you got here and are still with me, then you can see how things should only slow down, when they need to slow down. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-19182) Incremental Publish after Full Publish WRT dodeploy markers

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19182?page=com.atlassian.jira.plugi... ] Nick Boldt reassigned JBIDE-19182: ---------------------------------- Assignee: Rob Stryker > Incremental Publish after Full Publish WRT dodeploy markers > ----------------------------------------------------------- > > Key: JBIDE-19182 > URL: https://issues.jboss.org/browse/JBIDE-19182 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.2.0.Final > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.4.3.Final > > > THis issue is opened in regards to comments by [~dlmiles] on https://issues.jboss.org/browse/JBIDE-18862 > I am saying you should block all 'deployment directory' file modifications when you know the AS is busy using the 'deployment directory' to "deploy" (a.k.a. starting) or "undeploy" (a.k.a. stopping) of a module (or the AS itself is starting/stopping in certain scenarios). Ideally you use a file watcher API when available so there is no busy/wait loop adding additional milliseconds of delays because the wait part is never instant. > But in an example scenario where you perform a Full Publish then 2 additional Incremental Publish ops immediately after, there is no reason to block the incrementals if you know the AS has not picked up the original Full Publish yet. You can effectively merge those two incrementals into the full publish operation behind the back of the AS. > But you are presented with a race scenario, you have already laid down the *.dodeploy at the end of the original Full Publish. So Eclipse needs to effectively notice that scenario exists, revoke and remember that instruction to the AS in an atomic way (what I mean by this is Eclipse knows for sure if it cancelled it in time, or if it was too late and the AS got to the full publish first and started deploying). > You need to do this so Eclipse can make file change modifications to the 'deployment directory' again. > Once Eclipse has completed the file change operations, if takes that remembered state and puts back the *.dodeploy file (even though this is an Incremental Publish operation). You can think of this like a "save state" and "restore state" pattern if that helps. Or you can think of this like the Eclipse target goal state for the AS (such as "AS:started" and "module.abc:started") is compared to the actual AS state (such as "AS: started" and "module.abc:stopped"), and Eclipse then brings them into alignment to do this it realizes it needs to lay down the *.dodeploy marker file (even though this is an incremental publish). > I think with the current marker file arrangements there maybe a tiny window of time where Eclipse IDE will get things wrong in respect of the AS ? But maybe ensuring both Eclipse IDE and the AS check the return value of the file delete for *.dodeploy whomever was successful in deleting the file wins, whichever party got the error "No Such File" loses and performs a rollback/cleanup of the situation to ensure it tries again soon. > So you can speak for the JBIDE side but can someone check the AS side ? File#delete(new File("foobar.dodeploy")) != true. The AS has to delete the command instruction file before it starts to process that command, but after it has laid down a state change file (*.isdeploying). > One of the goals of the marker files is that at no point in time is there a snapshot of the files that exist in the directory; that would leave an observer to interpret the wrong state. For example deleting one marker file before laying down the next would be bad, because there is a snapshot of time when no state marker file exists in the directory, leaving the observer to interpret that nothing is happening with that module. The alternative is to lay both the new file first then delete the old one, now there is a window of time when 2 marker files indicate state for 1 module, this is good and valid since the observer can clearly see the correct state. > So if you got here and are still with me, then you can see how things should only slow down, when they need to slow down. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23779) Archive old JBoss Tools versions on Downloads and What's New pages

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23779?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-23779: ------------------------------- Fix Version/s: 4.4.4.AM1 (was: 4.4.3.AM2) > Archive old JBoss Tools versions on Downloads and What's New pages > ------------------------------------------------------------------- > > Key: JBIDE-23779 > URL: https://issues.jboss.org/browse/JBIDE-23779 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: website > Affects Versions: 4.4.3.AM1 > Reporter: Xavier Coulon > Assignee: Xavier Coulon > Fix For: 4.4.4.AM1 > > > there are too many versions displayed on https://tools.jboss.org/documentation/whatsnew/. Having 3 elements (1 development and 2 stable items) would be enough. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23724) Integration tests: move webservices integration tests to jbosstools/webservice repo

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23724?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-23724: ------------------------------- Fix Version/s: 4.4.4.AM1 (was: 4.4.3.AM2) > Integration tests: move webservices integration tests to jbosstools/webservice repo > ------------------------------------------------------------------------------------ > > Key: JBIDE-23724 > URL: https://issues.jboss.org/browse/JBIDE-23724 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift, webservices > Affects Versions: 4.4.2.Final > Reporter: Jeff MAURY > Assignee: Jeff MAURY > Labels: integration-test > Fix For: 4.4.4.AM1 > > > we need to move jbosstools/webservices integration tests from their repo to the jbosstools/webservices tools repo -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-20529) Master JIRA for XML Validation Problems

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20529?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-20529: ------------------------------- Fix Version/s: 4.4.3.Final (was: 4.4.3.AM2) > Master JIRA for XML Validation Problems > --------------------------------------- > > Key: JBIDE-20529 > URL: https://issues.jboss.org/browse/JBIDE-20529 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: project-examples, server > Reporter: Rob Stryker > Labels: xtriage > Fix For: 4.4.3.Final > > > This JIRA is meant to be a master container jira for all xml validation issues. These include identifying projects that are enganging in bad xml behavior, projects that point to namespaces or xsd locations that no longer exist, example projects using relative paths for linking to other xsd, and others. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23583) Integration tests global refactoring: org.jboss.tools.freemarker.ui.bot.test

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23583?page=com.atlassian.jira.plugi... ] Nick Boldt reassigned JBIDE-23583: ---------------------------------- Assignee: Denis Golovin > Integration tests global refactoring: org.jboss.tools.freemarker.ui.bot.test > ---------------------------------------------------------------------------- > > Key: JBIDE-23583 > URL: https://issues.jboss.org/browse/JBIDE-23583 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: freemarker > Affects Versions: 4.4.2.Final > Reporter: Jeff MAURY > Assignee: Denis Golovin > Labels: freemarker, integration, integration_tests > Fix For: 4.4.4.AM1 > > > Maven command: > {code} > mvn clean verify -Dtest.module=org.jboss.tools.freemarker.ui.bot.test -DskipTests=false > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23583) Integration tests global refactoring: org.jboss.tools.freemarker.ui.bot.test

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23583?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-23583: ------------------------------- Fix Version/s: 4.4.4.AM1 (was: 4.4.3.AM2) > Integration tests global refactoring: org.jboss.tools.freemarker.ui.bot.test > ---------------------------------------------------------------------------- > > Key: JBIDE-23583 > URL: https://issues.jboss.org/browse/JBIDE-23583 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: freemarker > Affects Versions: 4.4.2.Final > Reporter: Jeff MAURY > Assignee: Denis Golovin > Labels: freemarker, integration, integration_tests > Fix For: 4.4.4.AM1 > > > Maven command: > {code} > mvn clean verify -Dtest.module=org.jboss.tools.freemarker.ui.bot.test -DskipTests=false > {code} -- 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