Built with Seam

You can find the full source code for this website in the Seam package in the directory /examples/wiki. It is licensed under the LGPL.

This page contains information for contributors working on the Weld Archetypes.


In order to help users get started with Weld, there should be Maven archetypes available for a user to create the basic scaffolding for a new project. The archetype should be optimized to produce a project build that is easy for Maven and Weld novices to grasp, in contrast to the Weld example POMs, which are optimized for ease of maintenance in a large project, like Weld.

For those not familiar with Maven archetypes, they allow you to create a bare-bones project, customized to your artifact and package name (organization domain). Archetypes typically generate POMs, which specify and retrieve the libraries your application depends on, boilerplate code, and sometimes even samples of classes, pages, and unit tests. More information about archetypes can be found at

Archetype Design Goals

The design goals of this project are geared towards answering the following question:

How can we make Weld as accessible as possible to novice users?

The Weld project team has focused heavily on making Weld feature-rich to fill the needs of experienced and talented professionals. The archetype presents a great opportunity to convey to the skeptical or inexperienced Java programmer that Weld is not only powerful, but easy to use and can help them be more productive (with action, not just words).

What we hope to accomplish:

  1. The generated application should contain whatever boilerplate the user will need to start their application (e.g., web.xml, beans.xml, context.xml, etc). The ideal artifacts should be the bare minimum the user can use to get their application started. If there are optional configurations or parameters, include them, commented-out, with an explanation of how they will be helpful. The dependency on Weld should be kept to a minimum (only the build if possible) to respect portability.
  2. The generated POM should be as minimal as it can be. Keep in mind that the user will be modifying it frequently if they actually pursue a Weld project. POM hierarchies and exotic plugins could potentially confuse novice users.
  3. Comments are mandatory. Each dependency needs a comment explaining what it does and why it is there so that the user can figure out if they can remove it or upgrade it. The less mysterious the POM is, the more comfortable novice users will be.
  4. There should be a few helpful build plugins like the Eclipse plugin and container helper plugins like the JBoss plugin or Jetty. Explain in the inline comments what they do and why the user wants to use them.
  5. There should be a minimal Hello World-style artifacts generated so the user can confirm that they built the application correctly and their container of choice supports Weld. Default applications should be very easy to delete.


The 1.0 Release will only include JSF archetypes.

We are going to narrow down the containers we test on to 4 containers. The generated applications will most likely work just fine in other containers that correctly follow the specification, but we are only testing on a limited number of containers due to time constraints. If volunteers would like to help test the archetypes with other containers we would be overjoyed to accommodate.

JEE Containers supported

  • Glassfish v3 (standalone, not the plugin)
  • JBoss AS 6.0

Servlet Containers supported

  • Tomcat 6.0.20
  • Jetty (the embedded plugin)

Features Needed for 1.0 Release

The following features are needed for a 1.0 release:


The following files need to be generated by the archetype:

  • pom.xml
  • web.xml
  • beans.xml
  • faces-config.xml
  • persistence.xml (with the exception of the minimal archetypes)


Examples included in the archetype should be tiny and easy to delete. They serve the same purpose as a Hello World application and are included for beginners to test their container, not to teach them how to write an application. If the examples grow too complex, they will become tedious for experienced users if it takes many operations to removed unneeded features.

  • A simple JSF 2.0 welcome page to confirm your container supports JSF 2.0.
  • A tiny CDI example to confirm your container supports Weld.
  • An integration test for weld components.
  • (optional) A single servlet 3.0 example?
  • (optional) A datasource pointing to an embedded database, such as HSQLDB or Derby?
  • (optional) A tiny JPA CRUD example to confirm container and datasource works?

Anything (optional) is meant to be included both if time allows and if it can be included in an elegant manner.

Building the archetypes from source

You will need a subversion client to check out the archetype source.

Install the archetypes locally

# Change to your workspace directory (where you store your projects)

# checkout the archetype source from SVN
svn co weld-archetypes

# switch to the new directory
cd weld-archetypes

# install the archetypes locally (won't be necessary once published to repos)
mvn clean install

Outstanding Issues and Questions

These are issues we are actively working on or will be addressing in the near future.


Nice to have: