Help

The Weld team has recently collaborated with members of the community, most notably Steven Boscarine, to provide you with a set of Maven archetypes that get you developing with CDI and JSF 2 in a jiffy. Today we are announcing that the 1.0.0-BETA1 version of the archetypes are available in the Maven Central Repository. Consider it a holiday present from us ;)

Now you can create a brand new project with a single command and get started writing your application with CDI without having to waste time messing around with mundane setup tasks!

Follow this guide to get started.

Tell me more

Maven archetypes are templates that you use to create a new Maven project that is customized to your organization domain name (groupId) and project name (artifactId). The Weld archetypes focus on creating Java EE 6 projects that can be run on any Java EE 6-compliant application server (e.g., Glassfish V3 or JBoss AS 6.0), as well as JSF 2.0 and CDI projects that run on Servlet Containers (e.g., Tomcat 6 or Jetty 6). At the moment, the only view layer that is offered is JSF 2, though we plan to have archetypes that setup Wicket and other technologies that integrate with CDI in the future.

There are currently three archetypes available:

  • weld-jsf-servlet-miminal: An archetype for creating an application using JSF 2.0 and CDI 1.0 for Servlet Containers (Tomcat 6 / Jetty 6)
  • weld-jsf-jee-minimal: An archetype for creating a minimal Java EE 6 application using JSF 2.0, CDI 1.0 and EJB 3.1 (persistence unit not included)
  • weld-jsf-jee: An archetype for creating a Java EE 6 application using JSF 2.0, CDI 1.0, EJB 3.1 and JPA 2.0 (persistence unit included)

The resulting project imports the weld-extensions-bom to provide compatible version numbers for the Java EE APIs and supporting libraries. Only servlet projects depend on Weld at runtime, in order to bring the CDI services in a servlet environment. The jee projects depend exclusively on the Java EE 6 platform.

Show me

After loading the archetype catalog, you can choose to generate the project from the commandline or an IDE like Eclipse, NetBeans, or IntelliJ IDEA. Here's a screenshot showing us creating a new Maven project from one of the Weld archetypes in Eclipse (using the m2eclipse plugin):

Create Maven project

The generated project includes a readme file with instructions on how to deploy the application (readme.txt), a Maven POM (pom.xml), boilerplate configuration, a demonstration of the JSF 2 and Bean Validation integration, and a start page that you can visit to confirm your application deployed correctly, shown below. The start page uses layout template and stylesheet. The graphics on the page are taken from prototypes that the JBoss.org design team has created for the Weld project branding.

There is no faster way to get started with CDI and JSF 2 than using these archetypes!

Still, there is room for improvement. We are looking for your feedback. Do you find them easy? Do they provide too little? Too much? What other features do you want?

Credits

I'd like to thank Steven Boscarine for his dedication to this initiative and for helping us keep the end goal in perspective, Sonatype for making it so streamlined for OSS projects to publish artifacts to the Maven Central repository with Nexus, and the JBoss.org design team for the graphics that give the start page a slick look!

25 comments:
 
19. Dec 2009, 06:18 CET | Link

Awesome. Thanks for your work, guys!

ReplyQuote
 
19. Dec 2009, 06:30 CET | Link
Nicolas Radde | nicolas.radde(AT)gmail.com
I'm always glad to see more maven archetypes. This help so much when you get started, while still keeping a well organized project.
Keep up the good work!
 
19. Dec 2009, 06:40 CET | Link
Michael Schuetz

Hi Dan,

great stuff. Absolutely fantastic, that things starts moving now. I used the weld-jsf-jee-Archetype out of Eclipse and deployed the demo to JBoss 6.0.0.M1 - it worked out of the box! Great Job!

Hm, obviously I need to learn which annotation come's from which API now. (-:

Inspite of beeing probably not yet qualified enough, I would like to give you a short feedback:

1) in general: the archetype is pretty simple an straightforward to use

2) the project structure looks nicely organized and quite common to a Seam-User

3) a deeper package structure would be nice (something like ejb, model, controller or so)

4) OK, the example is pretty simple - and Yes, I know, you didn't have to much time for that and I truly appreciate that you want the community to take part asap. What I do find a little bit misleading is that the example uses two domain objects: Widget for sample JPA usage (unfortunately, nothing new from JPA 2.0 included) and HelloWorld for sample CDI/JSF/303/el-access usage. I do not see where the WidgetRepositoryProducer-SLSB is used? Why not put things together to one simple CRUD-Widget-example? Well, there are lots of new changes, annotations so I personally would prefer to see one small All-in-One-example - OK, the Widgets could be accessed either with or without EJB's.

5) after 4) you hopefully could get rid of <h:outputText value=" All clear!" rendered="#{facesContext.postback and empty facesContext.messageList} (-:

I have just started to study the CDI-API, but maybe you can answer these probably simple questions? So I would be able to play around with the stuff by knowing what I am doing (-:

1) OK, I understand that #{widgets} from home.xhtml refers to WidgetListProducer.getWidgets() due to @Named. How would I change this after extending the Producer-Class with missing CRUD-methods? Can I annotate the class with @Named? Does it have a default scope? Do I still neet @Produces for the methods or is there a way to generalize this as well? The el-access to a method would be: #{widgetListProducer.widgets}?

2) I did not understand completely why do I need @Qualifier in @WidgetRepository. What would happen without this annotation?

3) Is there still a pages.xml construct or is that Seam3 stuff?

BTW, I really like the @Model-Sterotype thing!! Great to see this in action in your demo.

regards Michael

 
19. Dec 2009, 16:14 CET | Link
Benjamin

Great progress! :-)

But I didn't get it run in glassfish v3 embedded with your hints in readme.txt. Got it work after following glassfish embedded docu suggestions to add to pom.xml. (use target/test.war not test.war!) Maybe you can add this stuff to main pom until JBoss 6 embedded is flying or correct the readme for manual addition

Greets Benjamin

 
20. Dec 2009, 07:53 CET | Link
Alberto Gori
Benjamin wrote on Dec 19, 2009 10:14:
Great progress! :-) But I didn't get it run in glassfish v3 embedded with your hints in readme.txt. Got it work after following glassfish embedded docu suggestions to add to pom.xml. (use target/test.war not test.war!) Maybe you can add this stuff to main pom until JBoss 6 embedded is flying or correct the readme for manual addition Greets Benjamin

How did you got JavaDB started in embedded glassfish? I get a connection refused at port 1527 and I think that db service is not up. I tried with the glassish-embedded admin goal, but no luck!

 
20. Dec 2009, 15:13 CET | Link
Benjamin

Hi Alberto,

Yes I had the same problem and then started an external derby instance as workaround. Sorry, forgot to mention it in my last post! Well, but I'm not sure whether an internal db instance normally should be started together with glassfish embedded since the normal edition also does start it separately.

Greets Benjamin

 
20. Dec 2009, 18:21 CET | Link
Alberto Gori
Benjamin wrote on Dec 20, 2009 09:13:
Hi Alberto, Yes I had the same problem and then started an external derby instance as workaround. Sorry, forgot to mention it in my last post! Well, but I'm not sure whether an internal db instance normally should be started together with glassfish embedded since the normal edition also does start it separately. Greets Benjamin

You are right. Anyway I see an admin goal that should execute start-databse commands. I tried

<plugin>
  <groupId>org.glassfish</groupId>
    <artifactId>maven-embedded-glassfish-plugin</artifactId>
    <version>3.0-SNAPSHOT</version>
    <configuration>
      <goalPrefix>glassfish</goalPrefix>
      <app>${project.build.directory}/${build.finalName}.war</app>
      <port>8080</port>
      <contextRoot>/weld</contextRoot>
      <autoDelete>true</autoDelete>
      <command>start-database</command>
    </configuration>
    <executions>
      <execution>
      <phase>install</phase>
      <goals>
        <goal>start</goal>
        <goal>admin</goal>
        <goal>deploy</goal>
      </goals>
      </execution>
    </executions>
</plugin>

but I get Command start-database not found.

Another important feature we should enable is hot deployment. The last tutorial shown here by Gavin about CDI and Netbeans was amazing: Glassfish or Netbeans (I don't know if it's a IDE or AS feature) were able to hot deploy single beans (EJB and not EJB). If we can achieve a CDI, JSF2, EJB3.1m JPA2.0 mavenized application with bundled AS and Database and hot deployment for free, would be great!

 
20. Dec 2009, 20:38 CET | Link
Benjamin

I googled around this db problem and found that statement:

I do know that start-database and stop-database will not work because Embedded GlassFish does not bundle JavaDB.

Maybe the sun engineers will change their mind!

20. Dec 2009, 21:51 CET | Link
Michael Schuetz wrote on Dec 19, 2009 00:40:
3) a deeper package structure would be nice (something like ejb, model, controller or so) 4) OK, the example is pretty simple - and Yes, I know, you didn't have to much time for that and I truly appreciate that you want the community to take part asap.

Hello Michael,

Thank you for giving such detailed feedback. We greatly appreciate it. Regarding the package structure, we have a lot of debate interally about the size of the example. Archetypes are meant to be used by advanced users as well as beginners.

Generally an archetype consists of boilerplate code, which thankfully there is very little needed in CDI, as well as a POM an possibly a small hello world type application. Whatever example we put in has to be easy to delete so advanced users don't get annoyed and just clone our archetype and remove all the examples. Deleting 20 files is acceptable the first 10 or so times you use an archetype, but after you've built your 20th war, (as I can easily do in a year with prototypes), I fear our seasoned users would resent a rich example.

I don't believe the Maven community has come up with recommendations or best practices about the size of the starter application, so we can certainly make them richer if the community requests it. Do you have an opinion on the matter?

It is my opinion that our archetype example needs to be rich enough for you to confirm your POM works in your container. I always view the example applications as useful for QA more than teaching people best practices. The weld team has provided starter examples and are working on bringing the new Java EE 6 examples up to the high standard of quality that the Seam examples were. The examples are meant to teach you how to utilize the technology.

Of course, this project is done entirely for the benefit of the community, not the contributors. We make archetypes to make your job easier and you more productive. Community members such as yourself are doing us a huge favor by letting us know how we can make these archetypes more useful for you.

Thanks again for checking out our archetypes and helping us out with your feedback.

20. Dec 2009, 21:57 CET | Link
Steven Boscarine wrote on Dec 20, 2009 15:51:
...the archetype example needs to be rich enough for you to confirm your POM works in your container. I always view the example applications as useful for QA more than teaching people best practices.

Sorry, that sentence was poorly worded. I meant to say the example application generated by the archetype is meant more for QA-ing your POM and contianer whereas the weld examples are meant to teach you how to use CDI.

21. Dec 2009, 01:04 CET | Link
Drew Arrigoni
Deleting 20 files is acceptable the first 10 or so times you use an archetype, but after you've built your 20th war, (as I can easily do in a year with prototypes), I fear our seasoned users would resent a rich example.

Seasoned users would also take the project structure after they deleted those 20 files and make their own archetype out of it if they were that annoyed by it. ;)

Is there a way you can add like a clean flag, which will leave you without any stuff?

21. Dec 2009, 04:39 CET | Link
Drew Arrigoni wrote on Dec 20, 2009 19:04:
Is there a way you can add like a clean flag, which will leave you without any stuff?

...don't we wish!!! To my knowledge, there's no standard way to provide that sort of functionality. We've been contacting the folks at Maven to figure out just that sort of question. Obviously, if a reader has a good lead on that, please let us know and we'll do what we can. We'd love to be able to disable specific components like the examples, with flags. We'd also love to have flags for different platforms or container versions as well.

In an ideal world, we'd prefer to provide something that is useful to most of the developer community than encourage them to build their own. Ideally, developers should be solving business domain problems for their employers and not trying to figure out how to wire a POM to match their latest container point release. However, I fully understand that sometimes a developer can do a better job for their needs by writing their own archetype, but we're hoping they'll at least make a good faith effort to help us improve the archetype by providing suggestions.

 
21. Dec 2009, 22:26 CET | Link
Paul Mooney | paul.mooney(AT)live.com

This is great. I can't wait to see the Wicket archetype. It would be nice to have a more involved test. Maybe an integration test that involves the

WidgetListProducer.getWidgets()

method.

The WidgetRepositoryProducer has a comment saying weld will close the EntityManager? AFAIK Weld gives no special lifecycle management for the EntityManager. Are there any Docs about the relationship between weld and an EntityManager? In this example, since the EntityManager is retrieved using @PersistenceContext (not extended), isn't it going to close after a transaction completes, leaving you with a closed EntityManager stuck in the default (Conversation?) scope? Would a better example be to get the EntityManagerFactory and use a producer to retrieve the EM, and a disposer to close it?

 
22. Dec 2009, 00:36 CET | Link
Alberto Gori
Paul Mooney wrote on Dec 21, 2009 16:26:
It would be nice to have a more involved test.

I would like it too, but I don't see anything about integration test in Weld, actually. Maybe because we can use Weld-SE for our tests?

 
22. Dec 2009, 07:31 CET | Link
Michael Schuetz

Hi Steven,

thanks for the reply.

The weld team has provided starter examples and are working on bringing the new Java EE 6 examples up to the high standard of quality that the Seam examples were. The examples are meant to teach you how to utilize the technology.

Sounds good. You're right. I was just excited about the new archetypes and the new possibility to see the big picture of Java EE 6 in Action. I know, it's a Weld archetype, no one for Seam 3.

I don't believe the Maven community has come up with recommendations or best practices about the size of the starter application, so we can certainly make them richer if the community requests it. Do you have an opinion on the matter?

A tiny starter app is absolutely fine. I think one Model in a simple CRUD-Context covers everything important to get started quickly: ejb,jpa,jsf (including navigation),cdi and the glue stuff

It is my opinion that our archetype example needs to be rich enough for you to confirm your POM works in your container.

I totally agree. And that's the reason I would like to see EJB3.1 in Action as well.

Keep up the good work!

Michael

 
24. Dec 2009, 13:34 CET | Link
The WidgetRepositoryProducer has a comment saying weld will close the EntityManager?

That's a reference to a bug in Weld. Weld isn't supposed to be doing that. I believe I put a reference to the bug report in the comment.

 
24. Dec 2009, 13:36 CET | Link
Alberto Gori wrote on Dec 21, 2009 18:36:
Paul Mooney wrote on Dec 21, 2009 16:26:
It would be nice to have a more involved test.
I would like it too, but I don't see anything about integration test in Weld, actually. Maybe because we can use Weld-SE for our tests?

There is no integration test because the integration test framework for Weld and Seam 3, Arquillian, is still a work in progress. It's possible to use it to write tests, but there is no release to Maven central, where the generated project is going to look for libraries. So you can be sure we will have integration tests coming in the archetypes soon!

 
24. Dec 2009, 13:45 CET | Link
But I didn't get it run in glassfish v3 embedded with your hints in readme.txt. Got it work after following glassfish embedded docu suggestions to add to pom.xml. (use target/test.war not test.war!) Maybe you can add this stuff to main pom until JBoss 6 embedded is flying or correct the readme for manual addition

Hmm, I'm a bit puzzled as to why the embedded GlassFish V3 setup doesn't work for you. The plugin should already be configured for you if you generate a jee-minimal or jee project. The configuration in the archetype is slightly different from the documentation you've cited, which I believe has errors in it.

Note that I have never gotten Maven to recognize the glassfish:run command. I have to use embedded-glassfish:run, which I think is the correct command for the plugin. I have yet to understand what the goalPrefix does, so I have omitted it from the configuration.

 
24. Dec 2009, 14:21 CET | Link

I did more research and I've determined that this goalPrefix configuration setting suggested in the Embedded GlassFish Documentation is a fallacy. The goal prefix for the maven-embedded-glassfish-plugin is embedded-glassfish (making the run command embedded-glassfish:run). The reason that goal prefix is selected is explained here.

 
24. Dec 2009, 14:31 CET | Link

Oh, I see. I had forgotten to add the maven-embedded-glassfish-plugin to the jee archetype. It is only in the jee-minimal archetype in 1.0.0-BETA1. I've added it to trunk.

24. Dec 2009, 14:37 CET | Link

Actually, we could probably put together a clean goal using the antrun plugin. It would clean out known resources that we added, probably just the Java classes. It would even be possible to pass this command in sequence with archetype:generate if you know ahead of time you want a clean project. Let's explore that, Steven. The antrun plugin could even remove itself after it finished (since Ant pretty much lets you do whatever you want, including regexp).

Having a clean target would all us to make the provided sample a little more fancy, just because it is a one step delete.

 
27. Dec 2009, 14:39 CET | Link

I don't think NetBeans is hot deploying individual beans. It's just copying the new class files into the in-place deployment archive and restarting the application when you save. This is really no different than a really streamlined, incremental builder (i.e., hot upgrade). Don't confuse that with hot swapping of classes at runtime, which is a much more complicated task.

As I said in my book, the term hot deploy is so overloaded that it's really hard know what behavior is really being referred to.

 
29. Dec 2009, 07:03 CET | Link

I try to run the project generated from the archetypes on embedded-glassfish.

This works fine with weld-jsf-jee-minimal.

But it does not work with weld-jsf-jee. First problem is that the maven-embedded-glassfish-plugin is not included in the pom (as stated by Dan above). But when I include the snippet from a pom generated by weld-jsf-jee-minimal, it still does not work. The error message is:

SEVERE: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener Has this something to do with the problem (discussed above) that the DB is not started?

Has anybody a some detailed instructions how to run the project generated with weld-jsf-jee in embedded-glassfish?

Thanks. jonas

04. Mar 2010, 02:57 CET | Link

Will the 1.0 version be released? The current archetype still uses JSF 2 RC dependencies..

 
04. Oct 2014, 13:23 CET | Link
jam

With the help of your residence broker create a video in which you reminisce about the home, the remembrances in it, the updates you made and the shared times. Walk around the community - share with the prospective client all the benefits of your community. Sell Property fast

Post Comment