<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/30/2013 08:16 AM, Antonio
Goncalves wrote:<br>
</div>
<blockquote
cite="mid:CAKawoOZ-vjPFKFKEDx=kRCbL75bkAfa4mfW86fnXMiV2s3VsCA@mail.gmail.com"
type="cite">
<div dir="ltr">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 :
<div><br>
</div>
<div>
<div><font face="courier new, monospace">beans setup</font></div>
<div><font face="courier new, monospace">ejb setup</font></div>
<div><font face="courier new, monospace">faces setup</font></div>
<div><font face="courier new, monospace">jms setup</font></div>
<div><font face="courier new, monospace">jstl setup</font></div>
<div><font face="courier new, monospace">jta setup</font></div>
<div><font face="courier new, monospace">persistence setup
--provider ECLIPSELINK --container GLASSFISH_3
--jndiDataSource</font></div>
<div><font face="courier new, monospace">rest setup
--activatorType</font></div>
<div><font face="courier new, monospace">servlet setup
--quickstart</font></div>
<div><font face="courier new, monospace">soap setup</font></div>
<div><font face="courier new, monospace">validation setup
--provider JAVA_EE --traversableResolver</font></div>
</div>
<div><br>
</div>
<div>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 <font
face="courier new, monospace">beans-new</font> is entered,
Forge would go <font face="courier new, monospace">if beans
is not setup, then I invoke beans-setup</font>", "if the
command <font face="courier new, monospace">ejb-new</font> is
entered, Forge would go <font face="courier new, monospace">if
ejb is not setup, then I invoke ejb-setup</font>"</div>
<div><br>
</div>
<div>That would save some bugs (developers forgetting to setup
things), less typing and shorter scripts.</div>
<div><br>
</div>
<div>What do you think, could this be possible for most of the
cases ?</div>
<div>
<br>
</div>
<div>Antonio</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/8/26 Lincoln Baxter, III <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hey Antonio!
<div><br>
</div>
<div>(Sorry for the late reply, I was gone over the
weekend.) </div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://github.com/forge/core/blob/2.0/projects/api/src/main/java/org/jboss/forge/addon/projects/ProjectType.java"
target="_blank">https://github.com/forge/core/blob/2.0/projects/api/src/main/java/org/jboss/forge/addon/projects/ProjectType.java</a><br>
</div>
<div><br>
</div>
<div>This is used in the new-project command like so:</div>
<div><br>
</div>
<div>`new-project --named "blah" --type javaee-7 --version
1.0 --topLevelPackage org.blah`</div>
<div><br>
</div>
<div>
Now, the interesting thing is that depending on the
project type, we can also specify additional parameters
that will become activated:</div>
<div><br>
</div>
<div>
<div><br>
</div>
<div>`new-project --named "blah" --type javaee-7
--version 1.0 --topLevelPackage org.blah --profile <b>web/full</b>`</div>
</div>
<div><br>
</div>
<div>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.</div>
</div>
<div class="gmail_extra">
<div>
<div class="h5">
<br>
<br>
<div class="gmail_quote">On Mon, Aug 26, 2013 at 9:13
AM, Antonio Goncalves <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:antonio.mailing@gmail.com"
target="_blank">antonio.mailing@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Ok, thanks for pointing these
JIRAs. I've added my 2cts in a comment :
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://issues.jboss.org/browse/FORGE-378"
target="_blank">https://issues.jboss.org/browse/FORGE-378</a><span><font
color="#888888"><br>
</font></span></div>
<span><font color="#888888">
<div>
<br>
</div>
<div>Antonio</div>
</font></span></div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/8/25 Vineet
Reynolds Pereira <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:vpereira@redhat.com"
target="_blank">vpereira@redhat.com</a>></span><br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"><br>
Hey Antonio,<br>
I believe all of these would be
eventually covered by FORGE-957 <<a
moz-do-not-send="true"
href="https://issues.jboss.org/browse/FORGE-957"
target="_blank">https://issues.jboss.org/browse/FORGE-957</a>>
and maybe other related items in JIRA
(FORGE-378 <<a moz-do-not-send="true"
href="https://issues.jboss.org/browse/FORGE-378" target="_blank">https://issues.jboss.org/browse/FORGE-378</a>>
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.<br>
<br>
Vineet<br>
<div><br>
----- Original Message -----<br>
> From: "Antonio Goncalves" <<a
moz-do-not-send="true"
href="mailto:antonio.mailing@gmail.com"
target="_blank">antonio.mailing@gmail.com</a>><br>
> To: "forge-dev List" <<a
moz-do-not-send="true"
href="mailto:forge-dev@lists.jboss.org"
target="_blank">forge-dev@lists.jboss.org</a>><br>
> Sent: Sunday, August 25, 2013
7:36:49 PM<br>
> Subject: [forge-dev] How to
choose which Java EE version ?<br>
><br>
> Hi all,<br>
><br>
> I've realized that I wrote on the
forum (<br>
</div>
> <a moz-do-not-send="true"
href="https://community.jboss.org/thread/231843"
target="_blank">https://community.jboss.org/thread/231843</a>
), but maybe the development ML<br>
<div>> would have been more
appropriate. Here are some thoughts
and questions about<br>
> "how to ask Forge to generate a
Java EE 6 or Java EE 7 application" :<br>
><br>
> ----------------------------<br>
><br>
><br>
><br>
> Java EE 7 is out... and one day
will come Java EE 8, 9 and so on. So
we<br>
> should be able to ask JBoss Forge
to either generate a Java EE 6 or 7<br>
> application... and if we want to
be more precise, you could even go
into<br>
> choosing from Java EE 6, Web
Profile 6, Java EE 7 and a Web Profile
7<br>
> application. But how to choose a
version with JBoss Forge ?<br>
><br>
><br>
><br>
> Today, with JBoss Forge 1.x, you
create a project with a CLI without
giving<br>
> any version indication :<br>
><br>
><br>
><br>
><br>
</div>
> 1. new-project --named app1
--topLevelPackage org.app1 --type war<br>
<div>><br>
><br>
><br>
><br>
> Then, when you setup your
project, you give Forge some hints :<br>
><br>
><br>
><br>
><br>
</div>
> 1. persistence setup --provider
ECLIPSELINK --container GLASSFISH_3<br>
> --named testPU ;<br>
> 2. validation setup --provider
HIBERNATE_VALIDATOR ;<br>
<div>><br>
><br>
><br>
><br>
> If the idea is to use Forge to
create Java EE applications running in
a<br>
> container (and not just in
standalone Java SE), the CLI to create
a project<br>
> misses some information, and the
setup is redundant. I would think of<br>
> something like :<br>
><br>
><br>
><br>
><br>
</div>
> 1. new-project --named app1
(...) --version JAVAEE_7 --container<br>
> GLASSFISH<br>
> 2. new-project --named app1
(...) --version JAVAEE_6 --container<br>
> GLASSFISH<br>
> 3. new-project --named app1
(...) --version JAVAEE_WEBPROFILE_6<br>
> --container GLASSFISH<br>
> 4. new-project --named app1
(...) --version JAVAEE_WEBPROFILE_7<br>
<div>> --container GLASSFISH<br>
><br>
><br>
><br>
><br>
> Note that I didn't put the
version of GlassFish because the
version of Java<br>
> EE implies the version of
GlassFish (eg. Java EE 6 == GlassFish
3, Java EE 7<br>
> == GlassFish 4). But note that
you could also specify the container
if<br>
> needed (e.g. generate a Java EE 6
app running on GlassFish 4)<br>
><br>
><br>
><br>
><br>
</div>
> 1. new-project --named app1
(...) --version JAVAEE_6 --container<br>
<div>> GLASSFISH_4<br>
><br>
><br>
><br>
><br>
> And, of course, the following
would be illegal (GF 3 cannot run a
Java EE 7<br>
> app) :<br>
><br>
><br>
><br>
><br>
</div>
> 1. new-project --named app1
(...) --version JAVAEE_7 --container<br>
> GLASSFISH_3<br>
><br>
><br>
><br>
><br>
> On this comment , Lincoln says that
the application should only depend on<br>
<div>> Java EE APIs. So I think the
pom.xml should only contain one of the<br>
> following dependency (depending
on the version of Java EE 7) :<br>
><br>
><br>
><br>
><br>
</div>
> 1. < dependency ><br>
> 2. < groupId > javax
</ groupId ><br>
> 3. < artifactId >
javaee-api </ artifactId ><br>
> 4. < version > 7.0 </
version ><br>
> 5. </ dependency ><br>
> 6. < dependency ><br>
> 7. < groupId > javax
</ groupId ><br>
> 8. < artifactId >
javaee-api </ artifactId ><br>
> 9. < version > 6.0 </
version ><br>
> 10. </ dependency ><br>
> 11. < dependency ><br>
> 12. < groupId > javax
</ groupId ><br>
> 13. < artifactId >
javaee-web-api </ artifactId ><br>
> 14. < version > 7.0 </
version ><br>
> 15. </ dependency ><br>
> 16. < dependency ><br>
> 17. < groupId > javax
</ groupId ><br>
> 18. < artifactId >
javaee-web-api </ artifactId ><br>
> 19. < version > 6.0 </
version ><br>
> 20. </ dependency ><br>
<div>><br>
><br>
><br>
><br>
> You do not need any extra
dependency if you want an application
to depend<br>
> only on Java EE. So that means
the following commands can also be
changed<br>
> from :<br>
><br>
><br>
><br>
><br>
</div>
> 1. persistence setup --provider
ECLIPSELINK --container GLASSFISH_3<br>
> --named testPU ;<br>
> 2. validation setup --provider
HIBERNATE_VALIDATOR ;<br>
><br>
><br>
><br>
><br>
> to<br>
><br>
><br>
><br>
><br>
> 1. persistence setup --named
testPU ;<br>
> 2. validation setup ;<br>
<div>><br>
><br>
><br>
><br>
> No need to specify the provider.
That's because you will use the
JPA/Bean<br>
> Validation/... default
implementation of the container
(GlassFish uses<br>
> EclipseLink, JBoss uses
Hibernate...). And to ease the
configuration and<br>
> portability, this means that you
don't need the <provider>
element in the<br>
> persistence.xml :<br>
><br>
><br>
><br>
><br>
</div>
> 1. <? xml version = "1.0"
encoding = "UTF-8" standalone = "no"
?><br>
> 2. < persistence xmlns = " <a
moz-do-not-send="true"
href="http://java.sun.com/xml/ns/persistence"
target="_blank">http://java.sun.com/xml/ns/persistence</a>
"<br>
> xmlns:xsi = " <a
moz-do-not-send="true"
href="http://www.w3.org/2001/XMLSchema-instance"
target="_blank">http://www.w3.org/2001/XMLSchema-instance</a>
" version =<br>
> "2.0" xsi:schemaLocation = " <a
moz-do-not-send="true"
href="http://java.sun.com/xml/ns/persistence"
target="_blank">http://java.sun.com/xml/ns/persistence</a><br>
> <a moz-do-not-send="true"
href="http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
target="_blank">http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd</a>
" ><br>
> 3. < persistence-unit name =
"javaone2013PU" transaction-type = "JTA"
><br>
> 4. < provider >
org.eclipse.persistence.jpa.PersistenceProvider
</<br>
> provider ><br>
> 5. (...)<br>
> 6. </ persistence-unit ><br>
> 7. </ persistence ><br>
<div>><br>
><br>
><br>
><br>
> Nor do you use the
<default-provider> element in
the validation.xml (and so<br>
> on).<br>
><br>
><br>
><br>
> I think the Java EE version
should be specified when the project
is created,<br>
> and then all the setups would use
the default container implementation.<br>
><br>
><br>
><br>
> --<br>
> Antonio Goncalves<br>
> Software architect and Java
Champion<br>
><br>
> Web site | Twitter | LinkedIn |
Paris JUG | Devoxx France<br>
><br>
</div>
>
_______________________________________________<br>
> forge-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:forge-dev@lists.jboss.org"
target="_blank">forge-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/forge-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
_______________________________________________<br>
forge-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:forge-dev@lists.jboss.org"
target="_blank">forge-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/forge-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Antonio Goncalves <br>
Software architect and Java Champion<br>
<br>
<a moz-do-not-send="true"
href="http://www.antoniogoncalves.org/"
target="_blank">Web site</a> | <a
moz-do-not-send="true"
href="http://twitter.com/agoncal"
target="_blank">Twitter</a> | <a
moz-do-not-send="true"
href="http://www.linkedin.com/in/agoncal"
target="_blank">LinkedIn</a> | <a
moz-do-not-send="true"
href="http://www.parisjug.org/"
target="_blank">Paris JUG</a> | <a
moz-do-not-send="true"
href="http://www.devoxx.fr/"
target="_blank">Devoxx France</a>
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:forge-dev@lists.jboss.org"
target="_blank">forge-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/forge-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
</div>
</div>
<span class="HOEnZb"><font color="#888888">Lincoln Baxter,
III<br>
<a moz-do-not-send="true" href="http://ocpsoft.org"
target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</font></span></div>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/forge-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Antonio Goncalves <br>
Software architect and Java Champion<br>
<br>
<a moz-do-not-send="true"
href="http://www.antoniogoncalves.org/" target="_blank">Web
site</a> | <a moz-do-not-send="true"
href="http://twitter.com/agoncal" target="_blank">Twitter</a> | <a
moz-do-not-send="true"
href="http://www.linkedin.com/in/agoncal" target="_blank">LinkedIn</a> | <a
moz-do-not-send="true" href="http://www.parisjug.org/"
target="_blank">Paris JUG</a> | <a moz-do-not-send="true"
href="http://www.devoxx.fr/" target="_blank">Devoxx France</a>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
forge-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/forge-dev">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
Hey,<br>
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 "
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
ACCEPT_DEFAULTS" flag to avoid to much prompt interaction.<br>
<br>
The forge distribution could come bundled with, for instance, a
beans.forge script. And the user would just have to type "run
beans.forge".<br>
<br>
But having these conventions built-in in Forge Core would be really
nice (and these conventions should be override easily with a DSL ? )<br>
<br>
Seb<br>
<br>
</body>
</html>