[forge-dev] How to choose which Java EE version ?
Sebastien Blanc
sblanc at redhat.com
Wed Oct 30 03:31:35 EDT 2013
On 10/30/2013 08:16 AM, Antonio Goncalves wrote:
> BTW, if most of the information is giving at project creation, do we
> still need to explicitly setup Java EE components ? At the moment we
> have the following :
>
> beans setup
> ejb setup
> faces setup
> jms setup
> jstl setup
> jta setup
> persistence setup --provider ECLIPSELINK --container GLASSFISH_3
> --jndiDataSource
> rest setup --activatorType
> servlet setup --quickstart
> soap setup
> validation setup --provider JAVA_EE --traversableResolver
>
> Most of these commands do not have parameters (except for persistence,
> rest, validation). So why not activate them by default ? Something
> like : "if the command beans-new is entered, Forge would go if beans
> is not setup, then I invoke beans-setup", "if the command ejb-new is
> entered, Forge would go if ejb is not setup, then I invoke ejb-setup"
>
> That would save some bugs (developers forgetting to setup things),
> less typing and shorter scripts.
>
> What do you think, could this be possible for most of the cases ?
>
> Antonio
>
>
> 2013/8/26 Lincoln Baxter, III <lincolnbaxter at gmail.com
> <mailto:lincolnbaxter at 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:
>
> https://github.com/forge/core/blob/2.0/projects/api/src/main/java/org/jboss/forge/addon/projects/ProjectType.java
>
> 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 at gmail.com <mailto:antonio.mailing at gmail.com>> 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 at redhat.com
> <mailto:vpereira at 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
>
> ----- Original Message -----
> > From: "Antonio Goncalves" <antonio.mailing at gmail.com
> <mailto:antonio.mailing at gmail.com>>
> > To: "forge-dev List" <forge-dev at lists.jboss.org
> <mailto:forge-dev at 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 (
> > 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 at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/forge-dev
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org <mailto:forge-dev at 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 at lists.jboss.org <mailto:forge-dev at 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 at lists.jboss.org <mailto:forge-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
Hey,
I think that having these kind of conventions would be really cool.
Notice that what you propose is somehow already possible by running a
forge script and activating the " ACCEPT_DEFAULTS" flag to avoid to much
prompt interaction.
The forge distribution could come bundled with, for instance, a
beans.forge script. And the user would just have to type "run beans.forge".
But having these conventions built-in in Forge Core would be really nice
(and these conventions should be override easily with a DSL ? )
Seb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20131030/c7afbba4/attachment-0001.html
More information about the forge-dev
mailing list