January 2016 - forge-issues - Jboss List Archives

[JBoss JIRA] (ROASTER-91) Add JavaInterfaceMethodImpl class

by Nicolas Challut (JIRA)

[ https://issues.jboss.org/browse/ROASTER-91?page=com.atlassian.jira.plugin... ] Nicolas Challut updated ROASTER-91: ----------------------------------- Description: method "bar" should be overrided in javaClass but it is empty. While searching in the code, I found that : {code} for (Method method : source.getMethods()) { if (method.isAbstract() && !target.hasMethod(method)) { {code} It seems that in JavaInterfaceSource the method aren't abstract by default (in the standars, interface method is abstract, key word is redundant). So, I see 2 ways to resolve this : # Change JavaInterface implementation to set all method abstract without add the key word # Change Methods#implementAbstractMethod() to handle JavaInterfaceSource type (if source instance of JavaInterfaceSource, addAll() ) What do you guys think about it ? UPDATE 21/01 : We could add a new class which extend MethodImpl to handle special behavior of interface. was: method "bar" should be overrided in javaClass but it is empty. While searching in the code, I found that : {code} for (Method method : source.getMethods()) { if (method.isAbstract() && !target.hasMethod(method)) { {code} It seems that in JavaInterfaceSource the method aren't abstract by default (in the standars, interface method is abstract, key word is redundant). So, I see 2 ways to resolve this : # Change JavaInterface implementation to set all method abstract without add the key word # Change Methods#implementAbstractMethod() to handle JavaInterfaceSource type (if source instance of JavaInterfaceSource, addAll() ) What do you guys think about it ? > Add JavaInterfaceMethodImpl class > --------------------------------- > > Key: ROASTER-91 > URL: https://issues.jboss.org/browse/ROASTER-91 > Project: Roaster > Issue Type: Bug > Affects Versions: 2.18.0.Final > Reporter: Nicolas Challut > Assignee: Nicolas Challut > > method "bar" should be overrided in javaClass but it is empty. > While searching in the code, I found that : > {code} > for (Method method : source.getMethods()) > { > if (method.isAbstract() && !target.hasMethod(method)) > { > {code} > It seems that in JavaInterfaceSource the method aren't abstract by default (in the standars, interface method is abstract, key word is redundant). > So, I see 2 ways to resolve this : > # Change JavaInterface implementation to set all method abstract without add the key word > # Change Methods#implementAbstractMethod() to handle JavaInterfaceSource type (if source instance of JavaInterfaceSource, addAll() ) > What do you guys think about it ? > UPDATE 21/01 : We could add a new class which extend MethodImpl to handle special behavior of interface. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-91) Add JavaInterfaceMethodImpl class

by Nicolas Challut (JIRA)

[ https://issues.jboss.org/browse/ROASTER-91?page=com.atlassian.jira.plugin... ] Work on ROASTER-91 started by Nicolas Challut. ---------------------------------------------- > Add JavaInterfaceMethodImpl class > --------------------------------- > > Key: ROASTER-91 > URL: https://issues.jboss.org/browse/ROASTER-91 > Project: Roaster > Issue Type: Bug > Affects Versions: 2.18.0.Final > Reporter: Nicolas Challut > Assignee: Nicolas Challut > > method "bar" should be overrided in javaClass but it is empty. > While searching in the code, I found that : > {code} > for (Method method : source.getMethods()) > { > if (method.isAbstract() && !target.hasMethod(method)) > { > {code} > It seems that in JavaInterfaceSource the method aren't abstract by default (in the standars, interface method is abstract, key word is redundant). > So, I see 2 ways to resolve this : > # Change JavaInterface implementation to set all method abstract without add the key word > # Change Methods#implementAbstractMethod() to handle JavaInterfaceSource type (if source instance of JavaInterfaceSource, addAll() ) > What do you guys think about it ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-91) Add JavaInterfaceMethodImpl class

by Nicolas Challut (JIRA)

[ https://issues.jboss.org/browse/ROASTER-91?page=com.atlassian.jira.plugin... ] Nicolas Challut updated ROASTER-91: ----------------------------------- Status: Open (was: Pull Request Sent) Issue has changed. > Add JavaInterfaceMethodImpl class > --------------------------------- > > Key: ROASTER-91 > URL: https://issues.jboss.org/browse/ROASTER-91 > Project: Roaster > Issue Type: Bug > Affects Versions: 2.18.0.Final > Reporter: Nicolas Challut > Assignee: Nicolas Challut > > method "bar" should be overrided in javaClass but it is empty. > While searching in the code, I found that : > {code} > for (Method method : source.getMethods()) > { > if (method.isAbstract() && !target.hasMethod(method)) > { > {code} > It seems that in JavaInterfaceSource the method aren't abstract by default (in the standars, interface method is abstract, key word is redundant). > So, I see 2 ways to resolve this : > # Change JavaInterface implementation to set all method abstract without add the key word > # Change Methods#implementAbstractMethod() to handle JavaInterfaceSource type (if source instance of JavaInterfaceSource, addAll() ) > What do you guys think about it ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-91) Add JavaInterfaceMethodImpl class

by Nicolas Challut (JIRA)

[ https://issues.jboss.org/browse/ROASTER-91?page=com.atlassian.jira.plugin... ] Nicolas Challut updated ROASTER-91: ----------------------------------- Summary: Add JavaInterfaceMethodImpl class (was: implementInterface doesn't work for JavaInterfaceSource) > Add JavaInterfaceMethodImpl class > --------------------------------- > > Key: ROASTER-91 > URL: https://issues.jboss.org/browse/ROASTER-91 > Project: Roaster > Issue Type: Bug > Affects Versions: 2.18.0.Final > Reporter: Nicolas Challut > Assignee: Nicolas Challut > > method "bar" should be overrided in javaClass but it is empty. > While searching in the code, I found that : > {code} > for (Method method : source.getMethods()) > { > if (method.isAbstract() && !target.hasMethod(method)) > { > {code} > It seems that in JavaInterfaceSource the method aren't abstract by default (in the standars, interface method is abstract, key word is redundant). > So, I see 2 ways to resolve this : > # Change JavaInterface implementation to set all method abstract without add the key word > # Change Methods#implementAbstractMethod() to handle JavaInterfaceSource type (if source instance of JavaInterfaceSource, addAll() ) > What do you guys think about it ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2585) Allow to obtain the cursor position of the current active editor window

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2585?page=com.atlassian.jira.plugin... ] George Gastaldi updated FORGE-2585: ----------------------------------- Component/s: UI - API > Allow to obtain the cursor position of the current active editor window > ----------------------------------------------------------------------- > > Key: FORGE-2585 > URL: https://issues.jboss.org/browse/FORGE-2585 > Project: Forge > Issue Type: Feature Request > Components: UI - API > Affects Versions: 3.0.0.Beta3 > Reporter: Claus Ibsen > Fix For: 3.x Future > > > For background see: https://github.com/fabric8io/fabric8/issues/5625 > It would be great if a forge command can obtain information about what is the current active window and the cursor position. > Essentially what we would like to know is that if the end user is currently editing a file, such as java or xml, and if so, what is the current cursor position in that file, or line number / column number etc. > Then the commands can use that to react accordingly. For example in fabric8 we want to be able to find out if the cursor is positioned in a Camel route and then let the command be smart to use that route etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2585) Allow to obtain the cursor position of the current active editor window

by Claus Ibsen (JIRA)

[ https://issues.jboss.org/browse/FORGE-2585?page=com.atlassian.jira.plugin... ] Claus Ibsen commented on FORGE-2585: ------------------------------------ Yeah being able to get the underlying resource abstraction would benefit also. Though a first goal would be just the line number / column number. So if we can have both that would be great. Though the internal api in eclipse jdt operates with an absolute position. So if we can have that as well? eg in a java method code block. I would need to dig out what code statement the cursor is at, so I can know if its a method call expression or something else etc. So maybe if we have 3 details - line number - column number (in the line) - absolute position (0 = first char ... N = last char) > Allow to obtain the cursor position of the current active editor window > ----------------------------------------------------------------------- > > Key: FORGE-2585 > URL: https://issues.jboss.org/browse/FORGE-2585 > Project: Forge > Issue Type: Feature Request > Affects Versions: 3.0.0.Beta3 > Reporter: Claus Ibsen > Fix For: 3.x Future > > > For background see: https://github.com/fabric8io/fabric8/issues/5625 > It would be great if a forge command can obtain information about what is the current active window and the cursor position. > Essentially what we would like to know is that if the end user is currently editing a file, such as java or xml, and if so, what is the current cursor position in that file, or line number / column number etc. > Then the commands can use that to react accordingly. For example in fabric8 we want to be able to find out if the cursor is positioned in a Camel route and then let the command be smart to use that route etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2585) Allow to obtain the cursor position of the current active editor window

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2585?page=com.atlassian.jira.plugin... ] George Gastaldi commented on FORGE-2585: ---------------------------------------- How about having a method like: {{T getSelectedRegionFor(Resource)}} and it could return a child element of the given resource ({{MethodSource}}, {{FieldSource}} when the resource is a {{JavaResource}} or {{Node}} if element is a {{XMLResource}} or even a {{String}} with the selected contents)? I am thinking on how useful would this API change be to make it easier for your code > Allow to obtain the cursor position of the current active editor window > ----------------------------------------------------------------------- > > Key: FORGE-2585 > URL: https://issues.jboss.org/browse/FORGE-2585 > Project: Forge > Issue Type: Feature Request > Affects Versions: 3.0.0.Beta3 > Reporter: Claus Ibsen > Fix For: 3.x Future > > > For background see: https://github.com/fabric8io/fabric8/issues/5625 > It would be great if a forge command can obtain information about what is the current active window and the cursor position. > Essentially what we would like to know is that if the end user is currently editing a file, such as java or xml, and if so, what is the current cursor position in that file, or line number / column number etc. > Then the commands can use that to react accordingly. For example in fabric8 we want to be able to find out if the cursor is positioned in a Camel route and then let the command be smart to use that route etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2585) Allow to obtain the cursor position of the current active editor window

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2585?page=com.atlassian.jira.plugin... ] George Gastaldi updated FORGE-2585: ----------------------------------- Forum Reference: https://github.com/fabric8io/fabric8/issues/5625 > Allow to obtain the cursor position of the current active editor window > ----------------------------------------------------------------------- > > Key: FORGE-2585 > URL: https://issues.jboss.org/browse/FORGE-2585 > Project: Forge > Issue Type: Feature Request > Affects Versions: 3.0.0.Beta3 > Reporter: Claus Ibsen > Fix For: 3.x Future > > > For background see: https://github.com/fabric8io/fabric8/issues/5625 > It would be great if a forge command can obtain information about what is the current active window and the cursor position. > Essentially what we would like to know is that if the end user is currently editing a file, such as java or xml, and if so, what is the current cursor position in that file, or line number / column number etc. > Then the commands can use that to react accordingly. For example in fabric8 we want to be able to find out if the cursor is positioned in a Camel route and then let the command be smart to use that route etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2585) Allow to obtain the cursor position of the current active editor window

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2585?page=com.atlassian.jira.plugin... ] George Gastaldi updated FORGE-2585: ----------------------------------- Fix Version/s: 3.x Future > Allow to obtain the cursor position of the current active editor window > ----------------------------------------------------------------------- > > Key: FORGE-2585 > URL: https://issues.jboss.org/browse/FORGE-2585 > Project: Forge > Issue Type: Feature Request > Affects Versions: 3.0.0.Beta3 > Reporter: Claus Ibsen > Fix For: 3.x Future > > > For background see: https://github.com/fabric8io/fabric8/issues/5625 > It would be great if a forge command can obtain information about what is the current active window and the cursor position. > Essentially what we would like to know is that if the end user is currently editing a file, such as java or xml, and if so, what is the current cursor position in that file, or line number / column number etc. > Then the commands can use that to react accordingly. For example in fabric8 we want to be able to find out if the cursor is positioned in a Camel route and then let the command be smart to use that route etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2585) Allow to obtain the cursor position of the current active editor window

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2585?page=com.atlassian.jira.plugin... ] George Gastaldi commented on FORGE-2585: ---------------------------------------- {{UISelection}} is the object responsible for selections in the UI. I think we could come with an API improvement on top of that returning the cursor position/line/column number. This object is reachable through {{UIContext}}. You can check if the selected file is a XML or Java class by checking the {{Resource}} instance returned with {{context.getSelection().get()}}. Thoughts? > Allow to obtain the cursor position of the current active editor window > ----------------------------------------------------------------------- > > Key: FORGE-2585 > URL: https://issues.jboss.org/browse/FORGE-2585 > Project: Forge > Issue Type: Feature Request > Affects Versions: 3.0.0.Beta3 > Reporter: Claus Ibsen > Fix For: 3.x Future > > > For background see: https://github.com/fabric8io/fabric8/issues/5625 > It would be great if a forge command can obtain information about what is the current active window and the cursor position. > Essentially what we would like to know is that if the end user is currently editing a file, such as java or xml, and if so, what is the current cursor position in that file, or line number / column number etc. > Then the commands can use that to react accordingly. For example in fabric8 we want to be able to find out if the cursor is positioned in a Camel route and then let the command be smart to use that route etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues January 2016