[JBoss JIRA] (FORGE-2177) Being able to create a new REST endpoint
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2177?page=com.atlassian.jira.plugin... ]
George Gastaldi closed FORGE-2177.
----------------------------------
Fix Version/s: 2.16.1.Final
(was: 2.x Future)
Resolution: Done
> Being able to create a new REST endpoint
> ----------------------------------------
>
> Key: FORGE-2177
> URL: https://issues.jboss.org/browse/FORGE-2177
> Project: Forge
> Issue Type: Sub-task
> Components: Java EE
> Affects Versions: 2.13.0.Final
> Reporter: Antonio Goncalves
> Assignee: Antonio Goncalves
> Labels: Starter
> Fix For: 2.16.1.Final
>
>
> It would be good to have a command to create a REST endpoint. A command like this :
> {code}
> rest-new-endpoint --named MyEndpoint
> {code}
> Would generate
> {code}
> @Path("/myEndpoint")
> public class CustomerEndpoint
> {
> }
> {code}
> Changing the path would be :
> {code}
> rest-new-endpoint --named MyEndPoint --path endpoint
> {code}
> This would generate :
> {code}
> @Path("/endpoint")
> public class CustomerEndpoint
> {
> }
> {code}
> The command also allows to generate several default methods (get, post, put, delete) with default mime type and so on :
> {code}
> rest-new-endpoint --named MyEndPoin --methods GET POST DELETE
> {code}
> This would generate :
> {code}
> @Path("/myEndpoint")
> public class CustomerEndpoint
> {
> @GET
> @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
> public Response doGet()
> {
> return Response.noContent().build();
> }
> @POST
> @Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
> public Response doPost()
> {
> return Response.noContent().build();
> }
> }
> {code}
> Also, a REST configuration class needs to be creates, such as :
> {code}
> @ApplicationPath("/rest")
> public class RestApplication extends Application
> {
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (FORGE-2177) Being able to create a new REST endpoint
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2177?page=com.atlassian.jira.plugin... ]
Antonio Goncalves reassigned FORGE-2177:
----------------------------------------
Assignee: Antonio Goncalves
> Being able to create a new REST endpoint
> ----------------------------------------
>
> Key: FORGE-2177
> URL: https://issues.jboss.org/browse/FORGE-2177
> Project: Forge
> Issue Type: Sub-task
> Components: Java EE
> Affects Versions: 2.13.0.Final
> Reporter: Antonio Goncalves
> Assignee: Antonio Goncalves
> Labels: Starter
> Fix For: 2.x Future
>
>
> It would be good to have a command to create a REST endpoint. A command like this :
> {code}
> rest-new-endpoint --named MyEndpoint
> {code}
> Would generate
> {code}
> @Path("/myEndpoint")
> public class CustomerEndpoint
> {
> }
> {code}
> Changing the path would be :
> {code}
> rest-new-endpoint --named MyEndPoint --path endpoint
> {code}
> This would generate :
> {code}
> @Path("/endpoint")
> public class CustomerEndpoint
> {
> }
> {code}
> The command also allows to generate several default methods (get, post, put, delete) with default mime type and so on :
> {code}
> rest-new-endpoint --named MyEndPoin --methods GET POST DELETE
> {code}
> This would generate :
> {code}
> @Path("/myEndpoint")
> public class CustomerEndpoint
> {
> @GET
> @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
> public Response doGet()
> {
> return Response.noContent().build();
> }
> @POST
> @Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
> public Response doPost()
> {
> return Response.noContent().build();
> }
> }
> {code}
> Also, a REST configuration class needs to be creates, such as :
> {code}
> @ApplicationPath("/rest")
> public class RestApplication extends Application
> {
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (FORGE-2177) Being able to create a new REST endpoint
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2177?page=com.atlassian.jira.plugin... ]
Antonio Goncalves updated FORGE-2177:
-------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/forge/core/pull/564
> Being able to create a new REST endpoint
> ----------------------------------------
>
> Key: FORGE-2177
> URL: https://issues.jboss.org/browse/FORGE-2177
> Project: Forge
> Issue Type: Sub-task
> Components: Java EE
> Affects Versions: 2.13.0.Final
> Reporter: Antonio Goncalves
> Assignee: Antonio Goncalves
> Labels: Starter
> Fix For: 2.x Future
>
>
> It would be good to have a command to create a REST endpoint. A command like this :
> {code}
> rest-new-endpoint --named MyEndpoint
> {code}
> Would generate
> {code}
> @Path("/myEndpoint")
> public class CustomerEndpoint
> {
> }
> {code}
> Changing the path would be :
> {code}
> rest-new-endpoint --named MyEndPoint --path endpoint
> {code}
> This would generate :
> {code}
> @Path("/endpoint")
> public class CustomerEndpoint
> {
> }
> {code}
> The command also allows to generate several default methods (get, post, put, delete) with default mime type and so on :
> {code}
> rest-new-endpoint --named MyEndPoin --methods GET POST DELETE
> {code}
> This would generate :
> {code}
> @Path("/myEndpoint")
> public class CustomerEndpoint
> {
> @GET
> @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
> public Response doGet()
> {
> return Response.noContent().build();
> }
> @POST
> @Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
> public Response doPost()
> {
> return Response.noContent().build();
> }
> }
> {code}
> Also, a REST configuration class needs to be creates, such as :
> {code}
> @ApplicationPath("/rest")
> public class RestApplication extends Application
> {
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (FORGE-2328) Move the Setup commands under a setup package or leave them under ui ?
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGE-2328:
----------------------------------------
Summary: Move the Setup commands under a setup package or leave them under ui ?
Key: FORGE-2328
URL: https://issues.jboss.org/browse/FORGE-2328
Project: Forge
Issue Type: Sub-task
Components: Java EE
Affects Versions: 2.16.0.Final
Reporter: Antonio Goncalves
Fix For: 2.x Future
In the Java EE addon, all the commands are under a {{ui}} package (eg. {{javaee.cdi.ui}}, {{javaee.ejb.ui}}).
The problem is that some {{setup}} commands are under the sub-package {{setup}} (eg. {{javaee.jpa.ui.setup.JPASetupWizard}}, {{javaee.jaxws.ui.setup.JAXWSSetupWizard}}) and others aren't ({{javaee.faces.ui.FacesSetupWizard}}).
It would be nice to opt for one (under {{setup}}) or the other (under {{ui}}) and make them all the same. The pb is that some APIs might be broken. The best choice (less breaking APIs) is to move them under {{ui}} : only JPA has an API under {{setup}}, some commands only have the impl under {{setup}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (FORGE-2316) Brainstorming on introducing "Stacks"
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/FORGE-2316?page=com.atlassian.jira.plugin... ]
Max Rydahl Andersen commented on FORGE-2316:
--------------------------------------------
Not all projects use pom's. (i.e. before project is created, polyglot mvn, gradle, etc.)
Not all projects will include that exact api dependency.
its fine to use pom.xml as a fallback but I just think it will be cutting forge short if it is
100% derived from pom.xml
> Brainstorming on introducing "Stacks"
> -------------------------------------
>
> Key: FORGE-2316
> URL: https://issues.jboss.org/browse/FORGE-2316
> Project: Forge
> Issue Type: Task
> Reporter: Antonio Goncalves
> Fix For: 2.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}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (FORGE-2316) Brainstorming on introducing "Stacks"
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2316?page=com.atlassian.jira.plugin... ]
Antonio Goncalves commented on FORGE-2316:
------------------------------------------
@Max why not rely on the {{pom.xml}} ? If you have {{javax.javaee-api}} version 7, then you know it's a Java EE 7 stack. Would you need more ?
> Brainstorming on introducing "Stacks"
> -------------------------------------
>
> Key: FORGE-2316
> URL: https://issues.jboss.org/browse/FORGE-2316
> Project: Forge
> Issue Type: Task
> Reporter: Antonio Goncalves
> Fix For: 2.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}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (FORGE-2316) Brainstorming on introducing "Stacks"
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/FORGE-2316?page=com.atlassian.jira.plugin... ]
Max Rydahl Andersen commented on FORGE-2316:
--------------------------------------------
btw. on an eclipse project forge could actually get/read a lot of this info from eclipse settings.
I expect similar should be possible for netbeans and maybe even intellij.
> Brainstorming on introducing "Stacks"
> -------------------------------------
>
> Key: FORGE-2316
> URL: https://issues.jboss.org/browse/FORGE-2316
> Project: Forge
> Issue Type: Task
> Reporter: Antonio Goncalves
> Fix For: 2.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}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (FORGE-2316) Brainstorming on introducing "Stacks"
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/FORGE-2316?page=com.atlassian.jira.plugin... ]
Max Rydahl Andersen commented on FORGE-2316:
--------------------------------------------
+100 for this. Also if whatever stacks is chosen could be put in a file *inside* the project (like a .forge file) so can be shared with team members this would be great.
> Brainstorming on introducing "Stacks"
> -------------------------------------
>
> Key: FORGE-2316
> URL: https://issues.jboss.org/browse/FORGE-2316
> Project: Forge
> Issue Type: Task
> Reporter: Antonio Goncalves
> Fix For: 2.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}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (ROASTER-70) setReturnType(Response.class) doesn't import Response
by Antonio Goncalves (JIRA)
Antonio Goncalves created ROASTER-70:
----------------------------------------
Summary: setReturnType(Response.class) doesn't import Response
Key: ROASTER-70
URL: https://issues.jboss.org/browse/ROASTER-70
Project: Roaster
Issue Type: Bug
Components: API
Affects Versions: 2.13.2.Final
Reporter: Antonio Goncalves
Fix For: 2.x Future
If you take the following code :
{code}
public static void main(String[] args) {
final JavaClassSource javaClassSource = Roaster.create(JavaClassSource.class);
javaClassSource.setPackage("org.agoncal.myproj").setName("MyEndpoint").addAnnotation(Path.class).setStringValue("/mypath");
MethodSource<?> doGet = javaClassSource.addMethod().setPublic().setName("method").setReturnType("javax.ws.rs.core.Response");
doGet.setBody("return null;");
System.out.println(javaClassSource);
}
{code}
It will generate the following code, which compile because it imports {{javax.ws.rs.core.Response}}.
{code}
package org.agoncal.myproj;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;
@Path("/mypath")
public class MyEndpoint {
public Response method() {
return null;
}
}
{code}
But if you change {{setReturnType("javax.ws.rs.core.Response")}} with {{setReturnType(Response.class)}}, {{Response}} is not imported, therefore, the code doesn't compile
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month