In my manual changes I update the pom.xml, but also all the deployment descriptors (persistence.xml, web.xml...).I've never written a plugin for Forge, I'm going to have a look at it right nowThanksAntonio2013/8/27 George Gastaldi <ggastald@redhat.com>
You might want to create a plugin to avoid the need to manually update.This plugin would just change the pom.xml afaik?And will this be available for JavaOne ;o) Just jokingI'm preparing a live coding demo using Forge to bootstrap a web app... but it generates Java EE 6 code so I have to manually update it (which is fine for the demo)2013/8/26 Lincoln Baxter, III <lincolnbaxter@gmail.com>Hey Antonio!(Sorry for the late reply, I was gone over the weekend.)Actually we definitely thought about this with Forge 2, and our current plan is to combine the two issues that Vineet linked with the new ProjectType API. So actually your syntax is very close to what we are already working on! Good to have some reassurance, though:This is used in the new-project command like so:`new-project --named "blah" --type javaee-7 --version 1.0 --topLevelPackage org.blah`Now, the interesting thing is that depending on the project type, we can also specify additional parameters that will become activated:`new-project --named "blah" --type javaee-7 --version 1.0 --topLevelPackage org.blah --profile web/full`So we can do web profile selection as part of the javaee7 project type, or we could just have multiple project types for each profile. It could go either way.Lincoln Baxter, IIIOn Mon, Aug 26, 2013 at 9:13 AM, Antonio Goncalves <antonio.mailing@gmail.com> wrote:Ok, thanks for pointing these JIRAs. I've added my 2cts in a comment :Antonio2013/8/25 Vineet Reynolds Pereira <vpereira@redhat.com>
Hey Antonio,
I believe all of these would be eventually covered by FORGE-957 <https://issues.jboss.org/browse/FORGE-957> and maybe other related items in JIRA (FORGE-378 <https://issues.jboss.org/browse/FORGE-378> for instance, but that is a dup). I don't think we have worked out the behavioral needs, but the idea is to allow the container or Java EE version dictate the Maven artifacts and versions that would be declared in the project during generation.
Vineet
> https://community.jboss.org/thread/231843 ), but maybe the development ML
----- Original Message -----
> From: "Antonio Goncalves" <antonio.mailing@gmail.com>
> To: "forge-dev List" <forge-dev@lists.jboss.org>
> Sent: Sunday, August 25, 2013 7:36:49 PM
> Subject: [forge-dev] How to choose which Java EE version ?
>
> Hi all,
>
> I've realized that I wrote on the forum (
> would have been more appropriate. Here are some thoughts and questions about> 1. new-project --named app1 --topLevelPackage org.app1 --type war
> "how to ask Forge to generate a Java EE 6 or Java EE 7 application" :
>
> ----------------------------
>
>
>
> Java EE 7 is out... and one day will come Java EE 8, 9 and so on. So we
> should be able to ask JBoss Forge to either generate a Java EE 6 or 7
> application... and if we want to be more precise, you could even go into
> choosing from Java EE 6, Web Profile 6, Java EE 7 and a Web Profile 7
> application. But how to choose a version with JBoss Forge ?
>
>
>
> Today, with JBoss Forge 1.x, you create a project with a CLI without giving
> any version indication :
>
>
>
>
>> 1. persistence setup --provider ECLIPSELINK --container GLASSFISH_3
>
>
>
> Then, when you setup your project, you give Forge some hints :
>
>
>
>
> --named testPU ;
> 2. validation setup --provider HIBERNATE_VALIDATOR ;
>> 1. new-project --named app1 (...) --version JAVAEE_7 --container
>
>
>
> If the idea is to use Forge to create Java EE applications running in a
> container (and not just in standalone Java SE), the CLI to create a project
> misses some information, and the setup is redundant. I would think of
> something like :
>
>
>
>
> GLASSFISH
> 2. new-project --named app1 (...) --version JAVAEE_6 --container
> GLASSFISH
> 3. new-project --named app1 (...) --version JAVAEE_WEBPROFILE_6
> --container GLASSFISH
> 4. new-project --named app1 (...) --version JAVAEE_WEBPROFILE_7
> --container GLASSFISH> 1. new-project --named app1 (...) --version JAVAEE_6 --container
>
>
>
>
> Note that I didn't put the version of GlassFish because the version of Java
> EE implies the version of GlassFish (eg. Java EE 6 == GlassFish 3, Java EE 7
> == GlassFish 4). But note that you could also specify the container if
> needed (e.g. generate a Java EE 6 app running on GlassFish 4)
>
>
>
>
> GLASSFISH_4> 1. new-project --named app1 (...) --version JAVAEE_7 --container
>
>
>
>
> And, of course, the following would be illegal (GF 3 cannot run a Java EE 7
> app) :
>
>
>
>
> GLASSFISH_3
>
>
>
>
> On this comment , Lincoln says that the application should only depend on
> Java EE APIs. So I think the pom.xml should only contain one of the> 1. < dependency >
> following dependency (depending on the version of Java EE 7) :
>
>
>
>
> 2. < groupId > javax </ groupId >
> 3. < artifactId > javaee-api </ artifactId >
> 4. < version > 7.0 </ version >
> 5. </ dependency >
> 6. < dependency >
> 7. < groupId > javax </ groupId >
> 8. < artifactId > javaee-api </ artifactId >
> 9. < version > 6.0 </ version >
> 10. </ dependency >
> 11. < dependency >
> 12. < groupId > javax </ groupId >
> 13. < artifactId > javaee-web-api </ artifactId >
> 14. < version > 7.0 </ version >
> 15. </ dependency >
> 16. < dependency >
> 17. < groupId > javax </ groupId >
> 18. < artifactId > javaee-web-api </ artifactId >
> 19. < version > 6.0 </ version >
> 20. </ dependency >
>> 1. persistence setup --provider ECLIPSELINK --container GLASSFISH_3
>
>
>
> You do not need any extra dependency if you want an application to depend
> only on Java EE. So that means the following commands can also be changed
> from :
>
>
>
>
> --named testPU ;
> 2. validation setup --provider HIBERNATE_VALIDATOR ;
>
>
>
>
> to
>
>
>
>
> 1. persistence setup --named testPU ;
> 2. validation setup ;
>> 1. <? xml version = "1.0" encoding = "UTF-8" standalone = "no" ?>
>
>
>
> No need to specify the provider. That's because you will use the JPA/Bean
> Validation/... default implementation of the container (GlassFish uses
> EclipseLink, JBoss uses Hibernate...). And to ease the configuration and
> portability, this means that you don't need the <provider> element in the
> persistence.xml :
>
>
>
>
> 2. < persistence xmlns = " http://java.sun.com/xml/ns/persistence "
> xmlns:xsi = " http://www.w3.org/2001/XMLSchema-instance " version =
> "2.0" xsi:schemaLocation = " http://java.sun.com/xml/ns/persistence
> http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd " >
> 3. < persistence-unit name = "javaone2013PU" transaction-type = "JTA" >
> 4. < provider > org.eclipse.persistence.jpa.PersistenceProvider </
> provider >
> 5. (...)
> 6. </ persistence-unit >
> 7. </ persistence >
>> _______________________________________________
>
>
>
> Nor do you use the <default-provider> element in the validation.xml (and so
> on).
>
>
>
> I think the Java EE version should be specified when the project is created,
> and then all the setups would use the default container implementation.
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
>
> forge-dev mailing list
> forge-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Antonio Goncalves
Software architect and Java Champion
Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev--
http://ocpsoft.org
"Simpler is better."
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev--
Antonio Goncalves
Software architect and Java Champion
Web site | Twitter | LinkedIn | Paris JUG | Devoxx France_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev--
Antonio Goncalves
Software architect and Java Champion
Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev