9:06 a.m.
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<https://issues.jboss.org/browse/FORGE-1067?focusedCommentId=12...;,
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 <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/>
11:39 a.m.
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>
To: "forge-dev List" <forge-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
8:13 a.m.
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>
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>
> To: "forge-dev List" <forge-dev(a)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(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/>
9:35 a.m.
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> 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>
>
> 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>
> > To: "forge-dev List" <forge-dev(a)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(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."
8:25 a.m.
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>
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> 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>
>
>>
>> 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>
>> > To: "forge-dev List" <forge-dev(a)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(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/>
8:30 a.m.
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> 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>
> 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>
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>
>>>
>>> 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>
>>> > To: "forge-dev List" <forge-dev(a)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(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 | Twitter | LinkedIn | Paris JUG | Devoxx France
>>
>> _______________________________________________
>> 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 | Twitter | LinkedIn | Paris JUG | Devoxx France
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
8:39 a.m.
Awesome!
Yeah, the EE7 stuff won't be ready for J1... sadly. We are shooting for a
November release. Looks like we are on track so far, just a few kinks to
work out in the new shell before we go into functionality production mode.
On Tue, Aug 27, 2013 at 9:30 AM, George Gastaldi <ggastald(a)redhat.com>wrote:
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>
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>
> 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> 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>
>>
>>>
>>> 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>
>>> > To: "forge-dev List" <forge-dev(a)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(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
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
8:39 a.m.
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
now
Thanks
Antonio
2013/8/27 George Gastaldi <ggastald(a)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?
Em 27/08/2013, às 10:26, Antonio Goncalves <antonio.mailing(a)gmail.com>
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>
> 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> 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>
>>
>>>
>>> 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>
>>> > To: "forge-dev List" <forge-dev(a)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(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
--
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/>
8:40 a.m.
Try this :) http://forge.jboss.org/docs/plugin_development/#content
On Tue, Aug 27, 2013 at 9:39 AM, Antonio Goncalves <
antonio.mailing(a)gmail.com> wrote:
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 now
Thanks
Antonio
2013/8/27 George Gastaldi <ggastald(a)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?
>
> Em 27/08/2013, às 10:26, Antonio Goncalves <antonio.mailing(a)gmail.com>
> 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>
>
>> 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> 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>
>>>
>>>>
>>>> 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>
>>>> > To: "forge-dev List" <forge-dev(a)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(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
>
--
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."
2:16 a.m.
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(a)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/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> 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>
>
>>
>> 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>
>> > To: "forge-dev List" <forge-dev(a)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(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/>
2:31 a.m.
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(a)gmail.com
<mailto: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:
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 <mailto:antonio.mailing@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(a)redhat.com
<mailto: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
----- Original Message -----
> From: "Antonio Goncalves" <antonio.mailing(a)gmail.com
<mailto:antonio.mailing@gmail.com>>
> To: "forge-dev List" <forge-dev(a)lists.jboss.org
<mailto: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 (
> 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 <mailto:forge-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org <mailto:forge-dev@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 <mailto:forge-dev@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 <mailto:forge-dev@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
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
4040
days inactive
4106
days old
10 comments
5 participants
participants (5)
-
Antonio Goncalves -
George Gastaldi -
Lincoln Baxter, III -
Sebastien Blanc -
Vineet Reynolds Pereira