Meeting minutes - 2013-10-30
by Lincoln Baxter, III
==============
#forge Meeting
==============
Meeting started by lincolnthree at 15:00:16 UTC. The full logs are
available athttp://transcripts.jboss.org/meeting/irc.freenode.org/forge/2013/forge....
.
Meeting summary
---------------
* Agenda (lincolnthree, 15:00:24)
* Work in progress (lincolnthree, 15:01:02)
* Next steps before Beta1 (lincolnthree, 15:02:22)
* Generated architectures (lincolnthree, 15:08:28)
* Generated architectures (lincolnthree, 15:08:28)
* Work in progress (status update) (lincolnthree, 15:19:25)
* Next steps (lincolnthree, 15:39:36)
* Finish scaffold port (lincolnthree, 15:39:43)
* Implement website requirements:
https://docs.google.com/document/d/1JkU-iALj1PqH7U3RC8j-4pEWhll7vocjZx29B...
(not worrying about design/theme yet) (lincolnthree, 15:40:06)
* Fix lingering issues with shell (lincolnthree, 15:40:17)
* Usability review for current commands (lincolnthree, 15:40:36)
* Usability review for addon creation (lincolnthree, 15:40:51)
* Write more commands! (lincolnthree, 15:41:06)
Meeting ended at 15:46:44 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* lincolnthree (92)
* vineetreynolds (67)
* gastaldi (44)
* agoncal (14)
* stalep (11)
* jbossbot (4)
* maxandersen (2)
* dbeer (2)
* jbott (2)
Meeting ended Wed Oct 30 15:46:44 2013 UTC. Information about MeetBot at
http://wiki.debian.org/MeetBot . (v 0.1.4)
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2013/forge.20...
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2013/forge.20...
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2013/forge.20...
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
11 years, 2 months
How to choose which Java EE version ?
by Antonio Goncalves
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=12794855&page...>,
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 years, 2 months
Several architectural styles in Forge (was Wondering about coding convention)
by Antonio Goncalves
2013/10/21 Vineet Reynolds Pereira <vpereira(a)redhat.com>
>
>
> IMHO we should not be putting persistence concerns in either the JSF beans
> or the REST resources.
> They should go into a service or a repository or whatever data access
> pattern is suitable for the context.
> This is where we lack any standardization at the moment, and it would be
> better to not limit this exercise to improving the conventions alone, but
> also the architecture.
>
Vineet, this is the topic I'm writing about at the moment. To be honest, I
quite like to have persistent concerns in JSF beans and REST for certain
projects... but not all, and that's where I thing Forge should give some
choices. What I'm writing is about having 3 different architectural styles
that could be resume like this (using CLI) :
*Current* (generates JSF/REST from entities) :
jsf-scaffold-from-entity
rest-scaffold-from-entity
*EJB Centric* (add a service layer to deal with persistence) :
ejb-scaffold-from-entity
jsf-scaffold-from-ejb
rest-scaffold-from-ejb
*REST centric* (the JSF backing beans use the REST endpoint, using JAX-RS
2.0 Client API) :
rest-scaffold-from-entity
jsf-scaffold-from-rest
I will let you know when the post is written, it will be clearer
--
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 years, 2 months
Wondering about coding convention #philosophy
by Antonio Goncalves
Hi all,
I love Forge because it generates code. And that's why my customers start
to love it too. Basically, they look at Forge as the "way to write
Java EEcode" or if you like "if those guys write code like this, then
we should".
I am digging into some details of the generated code (I am writing a blog
about several architectural styles starting with Forge) and I feel coding
convention should be homogenized. I know extensions are written by
different individuals, but some basic coding conventions should be applied.
For example, when you generate a web app with REST and Faces scaffolding,
you get some difference :
- Faces Backing Bean use *query builder* (e.g getAll method is
entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();
and
- REST Endpoint use *dynamic queries* (the list all method is "SELECT
DISTINCT b FROM Book b ORDER BY b.id"))
Method names are different and do the same :
- JSF : getAll
- REST : listAll
Attributes
- private EntityManager em;
- private EntityManager entityManager; // em would be better
Or the use of this keyword (JSF beans use this.entityManager instead
of directly em in REST)
And there are several examples like this. If Forge is seen as "the way of
writing code" maybe something should be created to get homogenized code.
PMD, Checkstyle, human review and so one.....
Just wondering....
--
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 years, 2 months
Entity field creation in 1.4.1
by David Beer
Hi All
I am trying to add a field to my entity using a OneToMany relationship and
specifying the type, however when I specify the type it says it can't find
the entity. The Entity of concern is a different package and is declared as
a dependency to the project.
Is there anyway to do this, add a field type and relationship with and
entity that exists in a different package and a dependency?
Thanks
David
11 years, 2 months
Fwd: Git tools
by George Gastaldi
The configuration looks ok. I may be missing something
George Gastaldi | Senior Software Engineer
JBoss Forge Team
Red Hat
-------- Original Message --------
Subject: Git tools
Date: Mon, 9 Sep 2013 18:34:05 +0300
From: Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>
To: George Gastaldi <ggastald(a)redhat.com>
Hey Gastaldi,
I have attached an archive of the git-tools addon together with a small
change in the parent pom (the jgit version).
As I wrote in the chat, I get the following error ATM:
SEVERE: Failed to start addon
[org.jboss.forge.addon:git-tools,2.0.0-SNAPSHOT] with classloader
[ModuleClassLoader for Module
"org.jboss.forge.addon.git-tools:2.0.0-SNAPSHOT_384942ba-8666-45c0-ae26-3c918c8f6b29"
from AddonModuleLoader]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied
dependencies for type [GitIgnoreConfig] with qualifiers [@Default] at
injection point [[BackedAnnotatedField] @Inject private
org.jboss.forge.addon.git.facet.GitIgnoreFacetImpl.config]
at
org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:405)
at
org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:327)
at
org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:178)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:209)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:521)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:507)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:482)
at
org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:538)
at
org.jboss.weld.bootstrap.api.helpers.ForwardingBootstrap.validateBeans(ForwardingBootstrap.java:75)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:144)
at
org.jboss.forge.furnace.container.cdi.lifecycle.WeldAddonLifecycleProvider.start(WeldAddonLifecycleProvider.java:59)
at
org.jboss.forge.furnace.impl.addons.AddonRunnable$1.call(AddonRunnable.java:77)
at
org.jboss.forge.furnace.impl.addons.AddonRunnable$1.call(AddonRunnable.java:71)
at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:34)
at
org.jboss.forge.furnace.impl.addons.AddonRunnable.run(AddonRunnable.java:70)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Thanks,
Ivan
11 years, 2 months
