[JBoss JIRA] (ROASTER-91) implementInterface doesn't work for JavaInterfaceSource
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/ROASTER-91?page=com.atlassian.jira.plugin... ]
George Gastaldi commented on ROASTER-91:
----------------------------------------
I think your first proposal is what makes more sense. Every method in a JavaInterface is abstract by nature (unless they are defined as static or default)
> implementInterface doesn't work for JavaInterfaceSource
> -------------------------------------------------------
>
> 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)
10 years, 3 months
[JBoss JIRA] (ROASTER-91) implementInterface doesn't work for JavaInterfaceSource
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/ROASTER-91?page=com.atlassian.jira.plugin... ]
George Gastaldi commented on ROASTER-91:
----------------------------------------
In this case, it seems that the method is created using: {{interfaceSource.addMethod().setAbstract(true).setName("doSomething").setReturnTypeVoid();}}
Notice the call to {{setAbstract(true)}}.
> implementInterface doesn't work for JavaInterfaceSource
> -------------------------------------------------------
>
> 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)
10 years, 3 months
[JBoss JIRA] (ROASTER-91) implementInterface doesn't work for JavaInterfaceSource
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/ROASTER-91?page=com.atlassian.jira.plugin... ]
George Gastaldi commented on ROASTER-91:
----------------------------------------
I can't reproduce your issue. The following passing test seems to be what you are talking about:
https://github.com/forge/roaster/blob/master/impl/src/test/java/org/jboss...
> implementInterface doesn't work for JavaInterfaceSource
> -------------------------------------------------------
>
> 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)
10 years, 3 months
[JBoss JIRA] (ROASTER-91) implementInterface doesn't work for JavaInterfaceSource
by Nicolas Challut (JIRA)
[ https://issues.jboss.org/browse/ROASTER-91?page=com.atlassian.jira.plugin... ]
Nicolas Challut updated ROASTER-91:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/forge/roaster/pull/48
This is my first PR, I don't know how to do that but I tried :)
> implementInterface doesn't work for JavaInterfaceSource
> -------------------------------------------------------
>
> 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)
10 years, 3 months
[JBoss JIRA] (ROASTER-91) implementInterface doesn't work for JavaInterfaceSource
by Nicolas Challut (JIRA)
[ https://issues.jboss.org/browse/ROASTER-91?page=com.atlassian.jira.plugin... ]
Work on ROASTER-91 started by Nicolas Challut.
----------------------------------------------
> implementInterface doesn't work for JavaInterfaceSource
> -------------------------------------------------------
>
> 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)
10 years, 3 months
[JBoss JIRA] (ROASTER-91) implementInterface doesn't work for JavaInterfaceSource
by Nicolas Challut (JIRA)
[ https://issues.jboss.org/browse/ROASTER-91?page=com.atlassian.jira.plugin... ]
Nicolas Challut updated ROASTER-91:
-----------------------------------
Summary: implementInterface doesn't work for JavaInterfaceSource (was: implementsInterface doesn't work for JavaInterfaceSource)
> implementInterface doesn't work for JavaInterfaceSource
> -------------------------------------------------------
>
> 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
>
> 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)
10 years, 3 months
[JBoss JIRA] (ROASTER-91) implementsInterface doesn't work for JavaInterfaceSource
by Nicolas Challut (JIRA)
Nicolas Challut created ROASTER-91:
--------------------------------------
Summary: implementsInterface doesn't work for JavaInterfaceSource
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
method "bar" should be overrided in my javaClass but my class 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)
10 years, 3 months
[JBoss JIRA] (ROASTER-91) implementsInterface doesn't work for JavaInterfaceSource
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 ?
was:
method "bar" should be overrided in my javaClass but my class 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 ?
> implementsInterface doesn't work for JavaInterfaceSource
> --------------------------------------------------------
>
> 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
>
> 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)
10 years, 3 months
[JBoss JIRA] (FORGE-2316) Brainstorming on introducing "Stacks"
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2316?page=com.atlassian.jira.plugin... ]
George Gastaldi edited comment on FORGE-2316 at 1/13/16 3:16 PM:
-----------------------------------------------------------------
About the filtering choices, we could introduce a interface (something like {{supports(Stack)}} and make {{PersistenceContainer}} implement it, just a thought, wdyt?
was (Author: gastaldi):
About the filtering choices, we could introduce a interface (something like {{supports(Stack)} and make {{PersistenceContainer}} implement it, just a thought, wdyt?
> Brainstorming on introducing "Stacks"
> -------------------------------------
>
> Key: FORGE-2316
> URL: https://issues.jboss.org/browse/FORGE-2316
> Project: Forge
> Issue Type: Sub-task
> Reporter: Antonio Goncalves
> Fix For: 3.x Future
>
>
> At the moment Forge generates code without having a real notion of a technical stack. For example, creating a JPA Entity for a Java EE 6 application could be different from a Java EE 7 application :
> * The {{persistence.xml}} version if different (2.0 / 2.1)
> * The {{properties}} are different (e.g. schema generation in 2.1)
> * The syntax is different ({{List<MyEntity> m = new ArrayList<MyEntity>}} while it could use diamond syntax for a Java EE 7 stack)
> The stack could be choosen when the project is created :
> * {{project-new --named myproj}} : let's the developper use Forge without any special stack
> * {{project-new --named myproj --stack JavaEE7}} : the generated code will follow Java EE 7
> h3. Possible stacks
> A stack would bundle certain facets. Therefore we could have as many stacks as needed. As an example, we could have the following stacks :
> * Java EE 6 : JPA 2.0, CDI 1.0, JSF 2.0, Bean Validation 1.0, JTA 1.1
> * Java EE 7 : JPA 2.1, CDI 1.1, JSF 2.2, Bean Validation 1.1, JTA 1.2, Batch 1.0
> * Micro Java EE 7 Service: JPA 2.1, CDI 1.1, JSF 2.2, Bean Validation 1.1, JTA 1.2, Batch 1.0 (but with special Microservice configuration)
> * Java EE 8 : JPA 2.1, CDI 2.0, JSF 2.3, Bean Validation 1.2, JTA 1.2, Batch 1.0, JCache 1.1, MVC 1.0
> * Spring 3.x
> * Spring 4.x
> * ....
> h3. Differences in having stacks
> h4. Filtering commands
> When you pick up a Stack, it gives you access or not to certain commands. For example, if you create a project with a Java EE 6 stack, you won't have access to any Batch, MVC... commands
> {code:title=Java EE 6 stack}
> $ project-new --named myproj --stack JavaEE6
> $ jpa-new-entity --named MyEntity
> {code}
> {code:title=Java EE 7 stack}
> $ project-new --named myproj --stack JavaEE7
> $ jpa-new-entity --named MyEntity
> $ mvc-new-controller --named MyController // only available on EE7
> {code}
> h4. Setting up command versions
> When you pick up a Stack, it filters the commands that have the right version for the right stack. For example, if you create a Java EE 6 stack, you will get JPA 2.0 commands, for a Java EE 7 stack, the JPA 2.1 commands. Also, the {{version}} parameters will be disabled
> {code:title=No stack}
> $ project-new --named myproj
> $ jpa-new-entity --named MyEntity --jpaVersion 2.1
> $ cdi-new-bean --named MyBean --cdiVersion 1.1
> {code}
> {code:title=Java EE 6 stack}
> $ project-new --named myproj --stack JavaEE6
> $ jpa-new-entity --named MyEntity // no --jpaVersion because it is automatically set to 2.0
> {code}
> {code:title=Java EE 7 stack}
> $ project-new --named myproj --stack JavaEE7
> $ jpa-new-entity --named MyEntity // no --jpaVersion because it is automatically set to 2.1
> $ jpa-new-converter --named MyConvert // JPA Converters are only available in 2.1
> {code}
> h4. API to define a Stack
> A stack could be defined with a fluent API such as :
> {code}
> stack("JavaEE7").includes(JavaEE7Facet).includes(JPA2.1Facet).excludes(SpringFacet)
> stack("JavaEE7").includes(JavaEE7Facet).includes(JPA2.1Facet).allowsFeature(WildflySwarm)
> stack("MyOwnStacks").includes(JavaEE7Stack).includes(MyFacet).includes(YourFacet)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (FORGE-2316) Brainstorming on introducing "Stacks"
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2316?page=com.atlassian.jira.plugin... ]
George Gastaldi edited comment on FORGE-2316 at 1/13/16 3:16 PM:
-----------------------------------------------------------------
Thanks for your feedback.
I haven't covered all the JavaEE setup commands yet. I may need your help to add a @StackConstraint on them all.
I renamed the {{NullStack}} to {{NoStack}}.
In {{StackFacet}}, the {{supports}} is needed to make sure that a Stack is enabled for certain ProjectTypes. For example, it doesn't make sense to create a NodeJS project and choose the JavaEE7 stack. The priority is meant for the "None" stack to be displayed up top, but I removed it anyway.
We need to better think about filtering choices. I think we can do that using the {{@StackConstraint}} and the {{StackInspector}} class somehow.
was (Author: gastaldi):
Thanks for your feedback.
I haven't covered all the JavaEE setup commands yet. I may need your help to add a @StackConstraint on them all.
I renamed the {{NullStack}} to {{NoStack}}.
In {{StackFacet}}, the {{supports}} is needed to make sure that a Stack is enabled for certain ProjectTypes. For example, it doesn't make sense to create a NodeJS project and choose the JavaEE7 stack. The priority is meant for the "None" stack to be displayed up top.
We need to better think about filtering choices. I think we can do that using the {{@StackConstraint}} and the {{StackInspector}} class somehow.
> Brainstorming on introducing "Stacks"
> -------------------------------------
>
> Key: FORGE-2316
> URL: https://issues.jboss.org/browse/FORGE-2316
> Project: Forge
> Issue Type: Sub-task
> Reporter: Antonio Goncalves
> Fix For: 3.x Future
>
>
> At the moment Forge generates code without having a real notion of a technical stack. For example, creating a JPA Entity for a Java EE 6 application could be different from a Java EE 7 application :
> * The {{persistence.xml}} version if different (2.0 / 2.1)
> * The {{properties}} are different (e.g. schema generation in 2.1)
> * The syntax is different ({{List<MyEntity> m = new ArrayList<MyEntity>}} while it could use diamond syntax for a Java EE 7 stack)
> The stack could be choosen when the project is created :
> * {{project-new --named myproj}} : let's the developper use Forge without any special stack
> * {{project-new --named myproj --stack JavaEE7}} : the generated code will follow Java EE 7
> h3. Possible stacks
> A stack would bundle certain facets. Therefore we could have as many stacks as needed. As an example, we could have the following stacks :
> * Java EE 6 : JPA 2.0, CDI 1.0, JSF 2.0, Bean Validation 1.0, JTA 1.1
> * Java EE 7 : JPA 2.1, CDI 1.1, JSF 2.2, Bean Validation 1.1, JTA 1.2, Batch 1.0
> * Micro Java EE 7 Service: JPA 2.1, CDI 1.1, JSF 2.2, Bean Validation 1.1, JTA 1.2, Batch 1.0 (but with special Microservice configuration)
> * Java EE 8 : JPA 2.1, CDI 2.0, JSF 2.3, Bean Validation 1.2, JTA 1.2, Batch 1.0, JCache 1.1, MVC 1.0
> * Spring 3.x
> * Spring 4.x
> * ....
> h3. Differences in having stacks
> h4. Filtering commands
> When you pick up a Stack, it gives you access or not to certain commands. For example, if you create a project with a Java EE 6 stack, you won't have access to any Batch, MVC... commands
> {code:title=Java EE 6 stack}
> $ project-new --named myproj --stack JavaEE6
> $ jpa-new-entity --named MyEntity
> {code}
> {code:title=Java EE 7 stack}
> $ project-new --named myproj --stack JavaEE7
> $ jpa-new-entity --named MyEntity
> $ mvc-new-controller --named MyController // only available on EE7
> {code}
> h4. Setting up command versions
> When you pick up a Stack, it filters the commands that have the right version for the right stack. For example, if you create a Java EE 6 stack, you will get JPA 2.0 commands, for a Java EE 7 stack, the JPA 2.1 commands. Also, the {{version}} parameters will be disabled
> {code:title=No stack}
> $ project-new --named myproj
> $ jpa-new-entity --named MyEntity --jpaVersion 2.1
> $ cdi-new-bean --named MyBean --cdiVersion 1.1
> {code}
> {code:title=Java EE 6 stack}
> $ project-new --named myproj --stack JavaEE6
> $ jpa-new-entity --named MyEntity // no --jpaVersion because it is automatically set to 2.0
> {code}
> {code:title=Java EE 7 stack}
> $ project-new --named myproj --stack JavaEE7
> $ jpa-new-entity --named MyEntity // no --jpaVersion because it is automatically set to 2.1
> $ jpa-new-converter --named MyConvert // JPA Converters are only available in 2.1
> {code}
> h4. API to define a Stack
> A stack could be defined with a fluent API such as :
> {code}
> stack("JavaEE7").includes(JavaEE7Facet).includes(JPA2.1Facet).excludes(SpringFacet)
> stack("JavaEE7").includes(JavaEE7Facet).includes(JPA2.1Facet).allowsFeature(WildflySwarm)
> stack("MyOwnStacks").includes(JavaEE7Stack).includes(MyFacet).includes(YourFacet)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months