September 2014 - jbosstools-issues

[JBoss JIRA] (JBIDE-16327) JaxrsFacetedProjectListener doesn't support JAX-RS 2.0

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16327?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen updated JBIDE-16327: ---------------------------------------- Priority: Critical (was: Minor) > JaxrsFacetedProjectListener doesn't support JAX-RS 2.0 > ------------------------------------------------------ > > Key: JBIDE-16327 > URL: https://issues.jboss.org/browse/JBIDE-16327 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: webservices > Affects Versions: 4.1.1.Final > Environment: Eclipse EE bundle 4.3.1 + JBoss Tools 4.1.1 > Reporter: Thomas Maslen > Assignee: Max Rydahl Andersen > Priority: Critical > Labels: respin-a > Fix For: 4.2.0.CR1 > > > More generally: JaxrsFacetedProjectListener supports exactly JAX-RS 1.1 but not 2.0? > (Perhaps that is intentional, and that's why various text labels in the public UI explicitly say "JAX-RS 1.1" rather than just "JAX-RS"?) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18004) Support launch/execution of specific Forge UICommands or UIWizards from Eclipse cheat sheets

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18004?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-18004: --------------------------------------------- and why do we want/need to change the title of wizards ? shouldn't this being called from cheatsheets being the same the user sees if he does it manually ? > Support launch/execution of specific Forge UICommands or UIWizards from Eclipse cheat sheets > -------------------------------------------------------------------------------------------- > > Key: JBIDE-18004 > URL: https://issues.jboss.org/browse/JBIDE-18004 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: forge > Affects Versions: 4.2.0.Beta3 > Reporter: Vineet Reynolds > Assignee: George Gastaldi > Priority: Critical > Fix For: 4.2.0.CR1 > > > The name of the command to be executed should be accepted as a parameter so that it can be directly launched from an Eclipse cheatsheet, instead of merely guiding the user to the quick access menu. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18112) vpe version should be 3.6, not 3.5.100

by Konstantin Marmalyukov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18112?page=com.atlassian.jira.plugi... ] Konstantin Marmalyukov commented on JBIDE-18112: ------------------------------------------------ Max, don't catch your point. Need to have 3.6.0 or leave 3.5.0? > vpe version should be 3.6, not 3.5.100 > -------------------------------------- > > Key: JBIDE-18112 > URL: https://issues.jboss.org/browse/JBIDE-18112 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: visual-page-editor-core > Affects Versions: 4.2.0.Beta3 > Reporter: Nick Boldt > Assignee: Konstantin Marmalyukov > Priority: Blocker > Fix For: 4.2.0.CR1 > > > As VPE for Luna includes new features/plugins [1] it should be upversioned to 3.6, not left as a maintenance version 3.5.100. > [1] http://download.jboss.org/jbosstools/builds/staging/devstudio.versionwatc... > New IUs include: > * org.jboss.tools.vpe.browsersim.debugger > * org.jboss.tools.vpe.browsersim.javafx.mock > * org.jboss.tools.vpe.preview > * org.jboss.tools.vpe.preview.core > * org.jboss.tools.vpe.preview.editor -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18112) vpe version should be 3.6, not 3.5.100

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18112?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-18112: --------------------------------------------- [~kmarmaliykov] it does not make sense to have 3.5.1 imo. We did change its integration from old cordova tooling to thym so it actually did change. > vpe version should be 3.6, not 3.5.100 > -------------------------------------- > > Key: JBIDE-18112 > URL: https://issues.jboss.org/browse/JBIDE-18112 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: visual-page-editor-core > Affects Versions: 4.2.0.Beta3 > Reporter: Nick Boldt > Assignee: Konstantin Marmalyukov > Priority: Blocker > Fix For: 4.2.0.CR1 > > > As VPE for Luna includes new features/plugins [1] it should be upversioned to 3.6, not left as a maintenance version 3.5.100. > [1] http://download.jboss.org/jbosstools/builds/staging/devstudio.versionwatc... > New IUs include: > * org.jboss.tools.vpe.browsersim.debugger > * org.jboss.tools.vpe.browsersim.javafx.mock > * org.jboss.tools.vpe.preview > * org.jboss.tools.vpe.preview.core > * org.jboss.tools.vpe.preview.editor -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18239) Create new update site zip(s) (rather than target platform zip) for JBT content needed for Central/EA site

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18239?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-18239: --------------------------------------------- The idea was that we don't need the entries for jboss tools based plugins in the actual central TP. > Create new update site zip(s) (rather than target platform zip) for JBT content needed for Central/EA site > ---------------------------------------------------------------------------------------------------------- > > Key: JBIDE-18239 > URL: https://issues.jboss.org/browse/JBIDE-18239 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, central, discovery, updatesite > Affects Versions: 4.2.0.CR1 > Reporter: Nick Boldt > Labels: f2f2014 > Fix For: 4.3.0.Alpha1 > > > In order to simplify the process for getting JBT features into Central (for JBDS) and EA (for both JBT/JBDS), it's been suggested (by [~maxandersen], who doesn't like opening JIRAs :D) that instead of a target platform which needs to be updated every time we spin or respin a build, we could instead just produce an update site containing the handful of IUs (cordovasim, arquillian, etc.). > We could further extend this idea to include all the things that currently are in BOTH JBT or JBDS and in Central, such as TestNG. > These would be produced as new zips using the JBT aggregate builder: > https://github.com/jbosstools/jbosstools-build-sites/tree/master/aggregate/ > Need to decide what to call this... "Extras" "JBT-not-in-JBDS" "Shared" ...? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18239) Create new update site zip(s) (rather than target platform zip) for JBT content needed for Central/EA site

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18239?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen updated JBIDE-18239: ---------------------------------------- Labels: f2f2014 (was: ) > Create new update site zip(s) (rather than target platform zip) for JBT content needed for Central/EA site > ---------------------------------------------------------------------------------------------------------- > > Key: JBIDE-18239 > URL: https://issues.jboss.org/browse/JBIDE-18239 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, central, discovery, updatesite > Affects Versions: 4.2.0.CR1 > Reporter: Nick Boldt > Labels: f2f2014 > Fix For: 4.3.0.Alpha1 > > > In order to simplify the process for getting JBT features into Central (for JBDS) and EA (for both JBT/JBDS), it's been suggested (by [~maxandersen], who doesn't like opening JIRAs :D) that instead of a target platform which needs to be updated every time we spin or respin a build, we could instead just produce an update site containing the handful of IUs (cordovasim, arquillian, etc.). > We could further extend this idea to include all the things that currently are in BOTH JBT or JBDS and in Central, such as TestNG. > These would be produced as new zips using the JBT aggregate builder: > https://github.com/jbosstools/jbosstools-build-sites/tree/master/aggregate/ > Need to decide what to call this... "Extras" "JBT-not-in-JBDS" "Shared" ...? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17910) Assign and List directive fixes and tests

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17910?page=com.atlassian.jira.plugi... ] Peter Palaga commented on JBIDE-17910: -------------------------------------- Steps to reproduce/verify: (1.1) Look at {{assign}} directive variants listed in [http://freemarker.org/docs/ref_directive_assign.html]. For each one of them, create one or more FTL templates that use it. (1.2) Having activated the {{OutlineContentProvider.fullAstShown}} preference, check visually, if the outline matches the template. There should also be no errors logged when the editor is opened. (1.3) Repeat (1.1) and (1.2) for the {{list}} directive documented in [http://freemarker.org/docs/ref_directive_list.html] Basically, I added unit tests that aim at checking the above, see: * {{org.jboss.ide.eclipse.freemarker.model.test.AssignmentDirectiveTest}} and * {{org.jboss.ide.eclipse.freemarker.model.test.ListDirectiveTest}} and the FTL files they use: * {{/org.jboss.ide.eclipse.freemarker.test/projects/testEditor/model/assign.txt.ftl}} * {{/org.jboss.ide.eclipse.freemarker.test/projects/testEditor/model/list.txt.ftl}} > Assign and List directive fixes and tests > ----------------------------------------- > > Key: JBIDE-17910 > URL: https://issues.jboss.org/browse/JBIDE-17910 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: freemarker > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 4.2.0.CR1 > > > (1) {{AssignmentDirective.isNestable()}} looks only if the directive ends with {{"/>}} which is simply wrong for {{assign}}, {{local}} and {{global}} directives. [{{assign}} documentation|http://freemarker.org/docs/ref_directive_assign.html] lists several possible variants of the directive. {{AssignmentDirective.isNestable()}} should cover them all and tests need to be added. > (2) It is clear from the usage of {{ItemSet.getFirstNestableItem(Stack<Item>)}} that it is supposed to return the last (as measured by time) item stored at the stack, not the first one. Therefore, {{getFirstNestableItem()}} needs to use a reverse order when iterating over the stack. > These two issues should fix the improper tree presented in outline (when rendered with {{OutlineContentProvider.fullAstShown}}. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18036) Decouple FTL target language syntax coloring

by Jiri Peterka (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18036?page=com.atlassian.jira.plugi... ] Jiri Peterka updated JBIDE-18036: --------------------------------- Fix Version/s: 4.2.0.CR2 (was: 4.2.0.CR1) > Decouple FTL target language syntax coloring > -------------------------------------------- > > Key: JBIDE-18036 > URL: https://issues.jboss.org/browse/JBIDE-18036 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: freemarker > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 4.2.0.CR2 > > Attachments: coloring-issues.png > > > This issue covers the requirement formulated in point (1) of my earlier comment in [JBIDE-11287|https://issues.jboss.org/browse/JBIDE-11287?focusedCommentId=...]. > The present Freemarker plugin has a hard-coded XML/HTML syntax coloring. Although XML/HTML may well be the most common target language of an FTL template, it is clearly not the only possible target language. One can target virtually any language or even plaintext, where {{<}} and {{<!--}} may have completely different meanings or no meanigs at all. Hardcoding XML highlighting for every file opened by the FTL editor is thus simply incorrect. > Let's define the present task as follows: > (1) Decouple the syntax coloring of the target language of a FTL template by introducing an interface (call it {{TargetLanguageSupport}}) that will provide the general functionality needed for coloring of target languages. > (2) At least two implementations of {{TargetLanguageSupport}} should be added: > (2.1) XML/HTML and > (2.2) plain text. > (3) Some kind of target-language detection should be added, e.g. based on file extensions, making XML/HTML syntax coloring active for files ending with {{\*.xml.ftl}}, {{\*.xhtml.ftl}}, {{\*.html.ftl}} and {{\*.htm.ftl}}. > (3.1) There should be a workspace-wide preference that will say for which file extensions will e.g. XML/HTML syntax coloring be active. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18036) Decouple FTL target language syntax coloring

by Jiri Peterka (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18036?page=com.atlassian.jira.plugi... ] Jiri Peterka updated JBIDE-18036: --------------------------------- Attachment: coloring-issues.png > Decouple FTL target language syntax coloring > -------------------------------------------- > > Key: JBIDE-18036 > URL: https://issues.jboss.org/browse/JBIDE-18036 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: freemarker > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 4.2.0.CR1 > > Attachments: coloring-issues.png > > > This issue covers the requirement formulated in point (1) of my earlier comment in [JBIDE-11287|https://issues.jboss.org/browse/JBIDE-11287?focusedCommentId=...]. > The present Freemarker plugin has a hard-coded XML/HTML syntax coloring. Although XML/HTML may well be the most common target language of an FTL template, it is clearly not the only possible target language. One can target virtually any language or even plaintext, where {{<}} and {{<!--}} may have completely different meanings or no meanigs at all. Hardcoding XML highlighting for every file opened by the FTL editor is thus simply incorrect. > Let's define the present task as follows: > (1) Decouple the syntax coloring of the target language of a FTL template by introducing an interface (call it {{TargetLanguageSupport}}) that will provide the general functionality needed for coloring of target languages. > (2) At least two implementations of {{TargetLanguageSupport}} should be added: > (2.1) XML/HTML and > (2.2) plain text. > (3) Some kind of target-language detection should be added, e.g. based on file extensions, making XML/HTML syntax coloring active for files ending with {{\*.xml.ftl}}, {{\*.xhtml.ftl}}, {{\*.html.ftl}} and {{\*.htm.ftl}}. > (3.1) There should be a workspace-wide preference that will say for which file extensions will e.g. XML/HTML syntax coloring be active. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15168) Show only macro and function declarations in Freemarker outline

by Jiri Peterka (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15168?page=com.atlassian.jira.plugi... ] Jiri Peterka closed JBIDE-15168. -------------------------------- Verified with JBDS 8.0.0.CR1, Fedora 20_64 > Show only macro and function declarations in Freemarker outline > --------------------------------------------------------------- > > Key: JBIDE-15168 > URL: https://issues.jboss.org/browse/JBIDE-15168 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: freemarker > Affects Versions: 4.1.0.Final > Reporter: Daniel Dekany > Assignee: Peter Palaga > Fix For: 4.2.0.CR1 > > > In the "FreeMarker IDE" Eclipse plugin, you should disable the outline view for now, as it's too broken to be useful, while it often slows template editing to crawl and is constantly flashing/redrawing as you type into the template, or even sometimes if you just move the cursor. > Regarding why it's broken: > * You show all the statements in it, which is way too much details and so it quickly becomes useless for overview and navigation. (Imagine if the Java outline did that, showing all if-s and for-s and assignments.) If should just list the macro and function declarations. > * It treats FreeMarker tags that don't end with {{/>}} as element openings, and then puts everything after that inside that element. But FreeMarker tags that start with {{#}} and can't have a body are implicitly closed. They are like {{img}} in HTML; {{<img ...>}} is the same as {{<img .../>}}. Similarly, {{<#assign x = 1>}} is the same as {{<#assign x = 1 />}}. > * It redraws the whole tree way to often. It slows things down, and the flashing it causes is annoying. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 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 September 2014