Re: [forge-dev] How to choose which Java EE version ?

You might want to create a plugin to avoid the need to manually update. This plugin would just change the pom.xml afaik? Em 27/08/2013, às 10:26, Antonio Goncalves <antonio.mailing(a)gmail.com&gt; escreveu: And will this be available for JavaOne ;o) Just joking I'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(a)gmail.com&gt; > 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: > > > https://github.com/forge/core/blob/2.0/projects/api/src/main/java/org/jbo... > > 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. > > > On Mon, Aug 26, 2013 at 9:13 AM, Antonio Goncalves < > antonio.mailing(a)gmail.com&gt; wrote: > >> Ok, thanks for pointing these JIRAs. I've added my 2cts in a comment : >> >> https://issues.jboss.org/browse/FORGE-378 >> >> Antonio >> >> >> 2013/8/25 Vineet Reynolds Pereira <vpereira(a)redhat.com&gt; >> >>> >>> 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 >>> >>> ----- Original Message ----- >>> > From: "Antonio Goncalves" <antonio.mailing(a)gmail.com&gt; >>> > To: "forge-dev List" <forge-dev(a)lists.jboss.org&gt; >>> > 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 ( >>> > https://community.jboss.org/thread/231843 ), but maybe the >>> development ML >>> > would have been more appropriate. Here are some thoughts and >>> questions about >>> > "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. new-project --named app1 --topLevelPackage org.app1 --type war >>> > >>> > >>> > >>> > >>> > Then, when you setup your project, you give Forge some hints : >>> > >>> > >>> > >>> > >>> > 1. persistence setup --provider ECLIPSELINK --container >>> GLASSFISH_3 >>> > --named testPU ; >>> > 2. validation setup --provider HIBERNATE_VALIDATOR ; >>> > >>> > >>> > >>> > >>> > 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 : >>> > >>> > >>> > >>> > >>> > 1. new-project --named app1 (...) --version JAVAEE_7 --container >>> > 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 >>> > >>> > >>> > >>> > >>> > 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) >>> > >>> > >>> > >>> > >>> > 1. new-project --named app1 (...) --version JAVAEE_6 --container >>> > GLASSFISH_4 >>> > >>> > >>> > >>> > >>> > And, of course, the following would be illegal (GF 3 cannot run a >>> Java EE 7 >>> > app) : >>> > >>> > >>> > >>> > >>> > 1. new-project --named app1 (...) --version JAVAEE_7 --container >>> > 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 >>> > following dependency (depending on the version of Java EE 7) : >>> > >>> > >>> > >>> > >>> > 1. < dependency > >>> > 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 > >>> > >>> > >>> > >>> > >>> > 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 : >>> > >>> > >>> > >>> > >>> > 1. persistence setup --provider ECLIPSELINK --container >>> GLASSFISH_3 >>> > --named testPU ; >>> > 2. validation setup --provider HIBERNATE_VALIDATOR ; >>> > >>> > >>> > >>> > >>> > to >>> > >>> > >>> > >>> > >>> > 1. persistence setup --named testPU ; >>> > 2. validation setup ; >>> > >>> > >>> > >>> > >>> > 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 : >>> > >>> > >>> > >>> > >>> > 1. <? xml version = "1.0" encoding = "UTF-8" standalone = "no" ?> >>> > 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(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/forge-dev >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >>> >> >> >> >> -- >> Antonio Goncalves >> Software architect and Java Champion >> >> Web site <http://www.antoniogoncalves.org/> | Twitter<http://twitter.com/agoncal> >> | LinkedIn <http://www.linkedin.com/in/agoncal> | Paris JUG<http://www.parisjug.org/> >> | Devoxx France <http://www.devoxx.fr/> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > > > > -- > Lincoln Baxter, III > http://ocpsoft.org > "Simpler is better." > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -- Antonio Goncalves Software architect and Java Champion Web site <http://www.antoniogoncalves.org/> | Twitter<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Paris JUG<http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/> _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev