[forge-dev] How to choose which Java EE version ?
Antonio Goncalves
antonio.mailing at gmail.com
Wed Oct 30 03:16:40 EDT 2013
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>
> 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> 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>
>>
>>>
>>> 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>
>>> > To: "forge-dev List" <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
>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>> _______________________________________________
>>> forge-dev mailing list
>>> 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
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
> _______________________________________________
> forge-dev mailing list
> 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20131030/b401f8fe/attachment-0001.html
More information about the forge-dev
mailing list