Maven is a project management framework hosted by the Apache Software Foundation (ASF) at http://maven.apache.org. The Maven project started as the result of build process needs inside ASF projects. Before Maven each Apache project had its own methods of compilation, distribution, web site generation, and etc. As a developer, one had to deal with each project’s build separately. In addition, people weren’t contributing enough to Apache projects since it was a hassle to get each one running on their locals.  So, there was a need for a uniform build system, and with the Apache Turbine project Maven took the scene.

Maven tries to make builds as easy as possible in a uniform way — if you know how to build one Maven project, you can build all of them. As Maven becomes more widely used, we believe that this will be the first thing that comes to mind any time someone mentions Maven.

Before You Start

You need to install Maven on your computer. You can either use the Maven that ships with IDEs / plugins, or you can download it from http://maven.apache.org/download.html.  Follow the installation instructions that are available for MacOs, Windows and Linux.

Meat & Potatoes

Probably the most important key concept of Maven is that it favors convention over configuration. With six lines of XML you can create a Maven project and build a jar file out of it. Maven offers common interfaces for building projects. You don’t need to deal with all the necessary libraries, the tasks to run to build the project, and etc.  There’s a good saying for this: before Maven, it was the era of build engineers.  Maven stops you from building the build, instead letting you focus on development to produce high quality code.  Maven has a detailed dependency management mechanism, so to get a project running on your local you don’t need to deal with jar files or the files that those jar files depend on — a la transitive dependency. Maven uses third-party public repositories for fetching all those artifacts, and there’s a good deal of them around.

Maven has a pluggable architecture, and the Maven core is actually very lightweight. It doesn’t even know about compiling code. It is just a matter of adding a compiler plugin. For Maven, a plugin is just another artifact to be fetched from a repository. Since the architecture is very pluggable, you can implement your own plugin and hook it into the build system easily.

In the sections below we’ll cover the core concepts of Maven in detail and discuss how you can begin using Maven in your own development projects.

The POM

POM stands for Project Object Model, and it’s what makes your project a Maven project. POM is an XML file that has the same declarative approach as in build.xml of Ant, or web.xml in Java web applications. POM describes the project with metadata for build processes, but it also contains data besides that which is needed for building, such as:

• the project’s relationship between Maven projects
• the list of team members, contributors, and developers
• source control management information
• the license of the project
• site generation information

So, it is a conceptual model that tries to cover nearly all the definitions of a software project. POM has a seamless integration with Java, but it is not just for Java projects. For instance, you can build FLEX distributable artifacts with israfil plugins, or you can create Microsoft binaries from C# codes, so it’s just a matter of plugins as we stated before. The best way to learn about the details of an XML file is to examine its XSD. Since XSD files are not human-readable, you can check out the XSD document of a Maven POM file that we shared at http://www.tinyurl.com/maven-xsddoc so you can easily see the tags that can be used inside POM.

Here is a sample skeleton for Project Object Model.

<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
    http://maven.apache.org/maven-v4_0_0.xsd">
   <parent />
   <groupId />
   <artifactId />
   <version />
   <packaging />
   <developers /> <contributors />
   <scm>...</scm>
   <build>
      <plugins>...</plugins>
   </build>
   <dependencies>...</dependencies>
   <repositories>...</repositories>
   <pluginRepositories>...</pluginRepositories>
   <profiles>...</profiles>
</project>

As you can see, all tags reside inside the project tag of POM.  Let’s go through the tags briefly. With the parent tag you can create parent-child relationships between your Maven projects.  The groupId,  artifactId and the version tags uniquely define a project coordinate.  With the packaging tag, project-specific packaging can be determined such as jar, war, and ear bundling.  The list of developers and contributors can be found inside the developers and contributors tags.  The source control definitions can be provided with the SCM tag, and the build tag allows you can hook in plugins needed for execution and configure them according to your needs.  With the repositories and pluginRepositories definitions you can tell Maven where to look to download the needed dependencies and plugins.  And finally, the profile tag allows you to generate different builds of a project like development, staging or production.

Here is the simplest POM. It’s just six lines of XML to define a Maven project.

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.openlogic.wazi</groupId>
    <artifactId>myapp</artifactId>
    <version>1.0.0</version>
</project>

When we run the mvn install command on this project Maven will try to compile the code, run the tests against that code, package the project as a jar file, and deploy it to the local repository. You may ask how that’s possible with just six lines of XML — after all, we haven’t defined any source folders, test folders, or the target folder that will contain the compiled classes.  Well, those are all coming from the convention.  And they are all defined in the Super POM.

Super POM has the same analogy with Java as in java.lang.Object.  Every Maven project extends this super POM.  It resides under the Maven uber jar.  Super POM defines the standard directory layout.  With Maven 2.0.9, super POM also locks the versions of common plugins to have stable builds.  So it’s best to use the latest Maven in order to have stable and better builds.  Super POM also contains the central Maven repository definition, http://repo1.maven.org/maven2. Note that there could be more than one POM through your project hierarchy.  Your project can have a parent project, and that parent project will extend the super POM.  Inside the child project, the elements of parent POM are inherited.  So, if you want to see the merged version of the POM, just run the command mvn help:effective-pom goal.

Build LifeCycle

We declared the project with the model, but we need a process for building the project out of this metadata.  To achieve this, Maven introduces the concept of lifecycles.  A lifecycle is a process for building and distributing an artifact, and it is clearly defined.  There are three built-in lifecycles of Maven: the default, which handles project deployment; the clean, which handles the cleaning of all project files generated by a previous build; and the site, which generates the project’s site documentation.  Each lifecycle contains phases in a specific order, and zero or more goals are attached to each phase.  So the atomic part here is the goal, and when we gather goals together we have the phases, and when phases are registered in specific order we have the lifecycle.  The illustration below shows the list of phases for the default lifecycle.

The default lifecycle of Maven first validates the project, like checking the consistency of pom.xml file, and then it tries to compile the code. If the compile is successful, it then tries to run the test against the compiled code, package the project in the specified format, run the integration tests against that package, verify the package by checking for the validity, install the verified package to the local repository, and finally deploy the package in the specified environment.

To execute phases/goals we can follow the notation below in the command line:

mvn phase
mvn phase:goal

We can also invoke multiple phases/goals within one command line, like:

mvn phase phase:goal
mvn phase:goal phase:goal

When we invoke the mvn integration-test command, Maven executes all the phases that are registered before that phase.  So the validate, compile, and package phases get executed before the integration-test phase.

Dependency Management

Maven is very capable of handling dependencies as the build tool.  If you’re still using the old-fashioned method of copying the necessary artifacts by hand to your lib folder,  believe us — it’s the beginning of the end for your project. You will find yourself in jar hell very soon.  So how can you avoid this?  The answer is Maven and its dependency mechanism.

If you specify a dependency by giving the coordinates of some third party project, which is the group identifier, artifact identifier, and the version, Maven will look for that artifact inside the defined repositories and fetch to the local repository.  Since everything is a plugin to Maven in the ecosystem, Maven-dependency-plugin is responsible for those actions.

Here is a sample dependency declaration for the project JUnit.  The dependency is defined by its coordinates, groupId, artifactId, and version.

<dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <version>4.8.1</version>
     <scope>compile</scope>
</dependency>

Scopes can also be provided while defining the dependency. There are six kinds of scopes.  The default scope is the compile.  All dependencies scoped as compile are in the project’s compile, test, and runtime classpaths by default.  Provided is a similar scope to compile, but it is expected that the dependency should be provided by JDK or the container at runtime.  For instance, servlet.jar is one of the dependencies that is usually scoped like this.  Because it will be provided by the web container, provided scope affects the compile and test classpaths.  Runtime scope means that the dependency is not needed for compilation, but it is needed at test execution and runtime so it affects the test and runtime classpaths.  For instance we might need a JDBC driver implementation only at runtime, so artifact will be scoped as provided.  Test scope means that dependency is only needed for test compilation and execution and not for the application itself.  It affects the test classpath.  System scope is the same as provided, but the dependency should be explicitly specified since it won’t be looked up in the repository.  It affects the compile and test classpaths. To declare the path of the dependency there is the <systemPath> tag that you can use.  Actually, we don’t recommend using this, because in our opinion every dependency should be “Mavenized” and go into the repository.  The last scope is import, which is introduced with Maven 2.0.9.  With import scope it is stated that the specified POM should be replaced with the dependencies in that POM’s <dependencyManagement> section.

Versions and Ranges on Dependencies

Maven follows this notation for versioning artifacts:

<major>.<minor>.<incremental> - <qualifier>

It starts with a major version and follows up with a minor one, and then an incremental version comes up.  At the end you can also add a qualifier in free-text format.  For example, both of these examples are valid artifact versions:

1.2.3
1.2.3-alpha-01

Be careful about qualifier notation since Maven uses string comparison while comparing two artifacts.  For example, 1.2.3-alpha-2 would be a later version than 1.2.3-alpha-10.  Zero left padding is needed on the alpha-2 qualifier to make it the earlier version.  You can also define ranges on versions while adding dependencies to your project, and you can define exclusion or inclusion on the range with the bracket notation like this:

<dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <version>[3.8,4.0)</version>
</dependency>

The version tag here states that it should be 3.8 at least, and it should be below 4.0.

Snapshot Qualifier

Maven also has a special qualifier, the SNAPSHOT, which indicates the artifact is created while the project is under active development.  When you install/release an artifact or fetch one from a remote repository, Maven expands this SNAPSHOT suffix with a date (UTC format)-time-buildnumber pattern.  So for an artifact such as myjar-1.0.0-SNAPSHOT.jar the result would be something like myjar-1.0.0-20100219.141012-1.jar.  And if you install a SNAPSHOT artifact to your local repository, it will not get converted to the date-time format in order to avoid filling your hard disk with snapshot versions.

By default Maven will periodically (on a daily basis) attempt to download the latest version of the snapshot.  You can change it to “always” or an “interval” specified in minutes by adjusting the setting in your repository configuration.

<releases>
      <updatePolicy>interval:30</updatePolicy>
</releases>

Managing Projects and Dependencies

Maven supports parent-child relationships between projects.  To declare a project as a parent, add the parent tag in your project’s pom.xml like this:

<project>
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>com.openglogic.wazi</groupId>
        <artifactId>parentapp</artifactId>
        <version>1.0.0</version>
    </parent>
    <artifactId>sampleapp</artifactId>
</project>

Just add the groupId, artifactId, and version of your parent project.  Maven will look into the parent folder and the local repository to locate that parent project.  It’s not mandatory to define groupId and version in your subproject, as Maven could inherit those fields from the parent.  Your project will also inherit dependencies that are declared in the parent project’s POM.  To see the merged version of the child project’s POM we can use mvn help:effective-pom command.  Actually, the most likely problem that you might encounter here is this: if you have a good number of child projects extending one parent POM, changing one dependency in the parent causes all child projects to face the consequences of that change.  Thus, it might be better to use the dependencyManagement feature.  Here’s the parent POM of a project that defines Commons-Logging with dependencyManagement at version 1.1.1:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.openlogic.wazi</groupId>
    <artifactId>parentapp</artifactId>
    <packaging>pom</packaging>
    <version>1.0</version>
    <dependencyManagement>
       <dependencies>
           <dependency>
               <groupId>commongs-logging</groupId>
               <artifactId>commongs-logging</artifactId>
               <version>1.1.1</version>
           </dependency>
       </dependencies>
    </dependencyManagement>
</project>

And here’s the POM of a child application.  As you can see, we didn’t define the version of Commons-Logging.  Instead, the version that we declared in the parent POM will be used.  And if we don’t define the Commons-Logging dependency in the child, it won’t be inherited from parent as in the previous case.

<project>
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>com.openlogic.wazi</groupId>
        <artifactId>parentapp</artifactId>
        <version>1.0</version>
    </parent>
    <artifactId>sampleapp</artifactId>
    <dependencies>
       <dependency>
           <groupId>commongs-logging</groupId>
           <artifactId>commongs-logging</artifactId>
       </dependency>
    </dependencies>
</project>

You may also have a project dependency hierarchy like this:

Here projectA depends on projectB and projectB depends on projectC.  So to compile projectA we need to compile projectB, but in order to compile projectB we need to compile projectC.  And that results to eight lines of Maven commands for just compiling projectA.

To overcome this, Maven supports a project modules approach.  We can create a modules project and have that project to point to the submodules. Here is the POM of modulesapp:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.openlogic.wazi</groupId>
    <artifactId>modulesapp</artifactId>
    <packaging>pom</packaging>
    <version>1.0</version>
    <name>modulesapp</name>
    <modules>
        <module>projectA</module>
        <module>projectB</module>
        <module>projectC</module>
    </modules>
</project>

By just compiling the modulesapp, we’ll have three submodules compiled automatically since they’re declared as modules inside the project. Maven-reactor-plugin will take the stage here and analyze the dependency hierarchy to define the order of compile.

Repositories

At some point each Java project that we’ve been developing heavily depends on other artifacts. For instance, a simple web application using the stack JSF, PrimeFaces, Seam, JPA, and Hibernate will have 40 dependencies like:

REPO/javax/activation/activation/1.1/activation-1.1.jar
REPO/antlr/antlr/2.7.6/antlr-2.7.6.jar
REPO/asm/asm/3.1/asm-3.1.jar
REPO/cglib/cglib/2.2/cglib-2.2.jar
REPO/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar
REPO/commons-codec/commons-codec/1.3/commons-codec-1.3.jar
REPO/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
REPO/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
REPO/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar
REPO/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
REPO/javax/el/el-api/1.0/el-api-1.0.jar
REPO/org/hibernate/hibernate-annotations/3.5.0-Beta-2/hibernate-annotations-3.5.0-Beta-2.jar
REPO/org/hibernate/hibernate-commons-annotations/3.2.0.Beta1/hibernate-commons-annotations-3.2.0.Beta1.jar
REPO/org/hibernate/hibernate-core/3.5.0-Beta-2/hibernate-core-3.5.0-Beta-2.jar
REPO/org/hibernate/hibernate-entitymanager/3.5.0-Beta-2/hibernate-entitymanager-3.5.0-Beta-2.jar
REPO/org/hibernate/hibernate-validator-legacy/4.0.2.GA/hibernate-validator-legacy-4.0.2.GA.jar
REPO/hsqldb/hsqldb/1.8.0.2/hsqldb-1.8.0.2.jar
REPO/javassist/javassist/3.10.0.GA/javassist-3.10.0.GA.jar
REPO/org/jboss/el/jboss-el/1.0_02.CR4/jboss-el-1.0_02.CR4.jar
REPO/org/jboss/seam/jboss-seam/2.2.0.GA/jboss-seam-2.2.0.GA.jar
REPO/org/jboss/seam/jboss-seam-jul/2.2.0.GA/jboss-seam-jul-2.2.0.GA.jar
REPO/org/jboss/seam/jboss-seam-mail/2.2.0.GA/jboss-seam-mail-2.2.0.GA.jar
REPO/org/jboss/seam/jboss-seam-ui/2.2.0.GA/jboss-seam-ui-2.2.0.GA.jar
REPO/org/hibernate/java-persistence/jpa-api/2.0-cr-1/jpa-api-2.0-cr-1.jar
REPO/javax/faces/jsf-api/1.2_13/jsf-api-1.2_13.jar
REPO/com/sun/facelets/jsf-facelets/1.1.14/jsf-facelets-1.1.14.jar
REPO/javax/faces/jsf-impl/1.2_13/jsf-impl-1.2_13.jar
REPO/jstl/jstl/1.2/jstl-1.2.jar
REPO/javax/transaction/jta/1.1/jta-1.1.jar
REPO/junit/junit/3.8.1/junit-3.8.1.jar
REPO/javax/mail/mail/1.4.1/mail-1.4.1.jar
REPO/postgresql/postgresql/8.4-701.jdbc3/postgresql-8.4-701.jdbc3.jar
REPO/org/primefaces/primefaces/1.0.0/primefaces-1.0.0.jar
REPO/quartz/quartz/1.6.0/quartz-1.6.0.jar
REPO/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar
REPO/org/slf4j/slf4j-api/1.5.8/slf4j-api-1.5.8.jar
REPO/org/slf4j/slf4j-nop/1.5.6/slf4j-nop-1.5.6.jar
REPO/org/testng/testng/5.9/testng-5.9.jar
REPO/xpp3/xpp3_min/1.1.3.4.O/xpp3_min-1.1.3.4.O.jar
REPO/xstream/xstream/1.1.3/xstream-1.1.3.jar

Of course, we can store those jars in source control, but it will:

• increase the storage
• make it dreadful to checkout the  project
• force us to version our jars, and we certainly don’t need that

To manage your project’s artifacts and dependencies Maven offers the repository mechanism. There are two types of repositories: a local one that caches the remote downloads your projects depends on and stores the build artifacts that you haven’t yet released; and the remote one that’s mostly hosted by a third party provider and is accessible with a variety of protocols like http. You can store artifacts with extensions like jars, wars, ears, ejbs, zips, and rar and resolve them through the Maven dependency management in your project. If there’s no external repository specified in the project’s POM, Maven looks for a local repository and the central Maven repository defined in the super POM. There are two types of repositories for hosting snapshot and release artifacts. Here’s a sample declaration for each. The first declaration is for a JBoss release repository. The id is uniquely identifying the repository, and it’s pointing to the given URL.

<repository>
    <id>jboss-repo</id>
    <name>The Release JBoss maven repo</name>
    <url>http://repository.jboss.org/maven2</url>
    <releases>
        <enabled>true</enabled>
    </releases>
</repository>

The second declaration is for snapshot artifacts. By default, Maven will not look into repositories for snapshot artifacts if the repository declaration is not tagged as snapshots with the enabled tag.

<repository>
    <id>jboss-snapshot-repo</id>
    <name>The Snapshot JBoss maven repo</name>
    <url>http://snapshots.jboss.org/maven2</url>
    <snapshots>
        <enabled>true</enabled>
    </snapshots>
</repository>

Searching for Artifacts Online

Searching for artifacts to add as dependencies to your projects can be a problem from time to time. You know that you need a specific jar, such as the Apache Jackrabbit core jar file, but you don’t know about its groupId, artifactId, or the latest version that is available. With the sites listed below, you can easily search for your artifacts online.

http://repository.apache.org
http://www.jarvana.com
http://mvnrepository.com
http://www.artifact-repository.org
http://www.mvnbrowser.com
http://mavensearch.net

Apache runs a Nexus at repository.apache.org. You can find all the Apache-related stuff in there. Another one of the sites above, Jarvana, is actually one of our favorites. It gives you the ability to search for an artifact based on the project name or even a class file name. Suppose you’re developing a web application and you came across a class not found problem that occurred at runtime. With Jarvana you can search for those classes and find the related Maven artifact. It also lists the Javadocs and other cool stuff if applicable.

IDE Support

For popular JAVA IDEs like NetBeans Eclipse or IDEA, you can find first-class support for Maven inside the IDEs. NetBeans and Intellij IDEA support Maven out of the box and ship with the latest version, Maven 3. For Eclipse there are two incubation projects at the moment. One of them is Eclipse Integration for Apache Maven, Eclipse IAM, which is also formerly known as the Q4E project. The other one is the m2eclipse plugin and it’s being maintained by Sonatype. m2eclipse is a must-have plugin if you’re developing on Eclipse. With m2eclipse you can check out Maven projects directly from source control as Maven projects. It supports source controls like Subversion, CVS, Git and many others. You can also create new projects by selecting archetypes.  It’ll take 30 seconds to get you started, for instance, with web applications. There’s also a nice POM editor bundled with the plugin so you don’t need to deal with the XML directly. We’ve includes some screenshots of the plugin below.

To checkout projects from source control:

To create a project with archetypes:

The pom.xml editor – the dependencies:

The Dependency Graph:

Finishing up

There’s no better way to learn the benefits of Maven than to give it a try.  If you’re starting from scratch or have a greenfield project, now is the perfect time to get started with Maven! Maven will ease the build process of your project, and it will be much simpler to manage the project with well-defined metadata. If you’re part of a group of developers working on the same project, you could also use Maven to create your own repository manager. (Nexus, Arcihva and Artifactory are other open source alternatives you can use for that.) Another way to get started with Maven is to create a company or project-specific POM to easily manage dependencies across your sub-projects.

Regardless of how you get started with Maven, here are a few tips to keep in mind:

• Keep your POM simple and readable.
• Use property references to avoid any hard coding.
• Use profiles to create different builds out of your project. Make it so that you can release early and release often — it’s a MUST in the land of agile/extreme programming.
• Follow the rule for Seperation of Concerns, or SoC. Arrange your Maven projects so that you have one artifact per project.
• Use IDE integrations for Maven — there’s a good deal of first class support for popular Java IDEs. Move yourself from stone age to iron age on that matter.
• And finally, do not use parameters for ignoring your tests, they’re evil!

Should you need additional resources on Maven, try the following books that you can find online for free:

http://www.sonatype.com/book

• Maven:The Complete Reference
• Maven By Example
• m2eclipse Book
• Nexus Book

http://www.maestrodev.com/better-build-maven

• Better Builds with Maven

Before You Start

Our tutorial assumes that you’re familiar with the following technologies:

• JavaServer Faces (JSF) and Facelets
• Dependency Injection Mechanism
• Bean Validation

You’ll also need to install the following applications in order to build the demo application from scratch, or to run it on your local machine:

• Java 6 (Java SDK 1.6) or greater
• NetBeans 6.8 bundled with GlassFish 3
• Maven, preferably the latest version 2.2.1 (Netbeans ships with Maven 3.0-SNAPSHOT, so that can also be used)

Meat & Potatoes

What’s New with Java EE 6?

Java EE 6 specification was finalized in December of 2009, bringing new and updated features to the world of enterprise application development. It introduces the profile approach, meant to focus both developers and applications on particular parts of the Java EE 6 platform. The first profile defined by the expert group is the Java EE 6 web profile, which attempts to specify the minimal configuration targeted for the development of typical web applications. Here are the elements of the web profile, with a few that we’ve chosen to explain in detail.

1. Servlet 3.0
   In web frameworks, servlets are used as an entry point to handle all incoming requests, so it could be said that they are the core elements of web-based applications. The new 3.0 version (specification JSR-315) offers innovative features like ease of development with annotations (@Servlet, @ServletFilter, @ServletContextListener) and annotations for restful services like @GET, @POST and more. It also offers pluggability and extensibility. The main aim here is to attain zero-configuration when working with other frameworks and libraries. Toward this end, a  new xml tag definition called <web-fragment> can be used to apply this feature. The web fragments, which are to be stored inside the jars of their respective libraries, will be merged by the container — so there’s no need for the developer to set up any configurations on the web descriptor file. Speaking of pluggability and extensibility, Servlet 3.0 also has a new application programming interface (API) which can be used to add servlets and filters with coding.
2. JavaServer Pages (JSP) 2.2
3. ExpressionLanguage (EL) 2.2
4. Debugging Support for Other Languages (JSR-45) 1.0
5. Standard Tag Library for JavaServer Pages (JSTL) 1.2
6. JavaServer Faces (JSF) 2.0
   Ever since  the release of JSF’s 1.X version, its aim was to be the go-to framework for building user interfaces and web applications. As it gained popularity with many application developers around the world, there was a growing awareness of terrific features like componenting, validation, navigation, i18n and others. However, as with so many wonderful things, flaws and disadvantages became more evident over time — like how complicated it could be to accomplish even a simple task such as creating your own custom JSF component. JSF version 2.0 aims to remedy these flaws by simplifying and easing development and introducing new features, like built-in Ajax support, which will make standard some of what have until now been third party solutions. Here’s a quick summary of the improvements that are part of JSF 2.0.
   • Composite components
     Implementing custom JSF components in 1.x is a real burden. You have to implement a UI component and Tag class, with the option of a Renderer for the markup, and then configure all these within faces-config and tld files. JSF 2.0 simplifies the procedure with the composite component approach introduced in Facelets.
   • Native Ajax Support
     JSF 2.0 provides built-in support for Ajax with its API and infrastructure.  A good example of the useful new components is f:ajax.
   • State Saving
     Since JSF 2.0 aims to handle requests partially with classes like PartialViewContext and PartialStateHolder (among others), it also attempts to make use of a partial mechanism to handle state saving. This has been implemented before, by Apache Trinidad, but PartialStateHolder and StateHelper classes provide a more elegant solution. The goal is to have a lightweight version of the saved state going back and forth in response to requests.
   • Scopes
     In addition to the request, session and application scopes, 2.0 also introduces view and flash scopes. View-scoped beans have a life span that is longer than a request, but shorter than session-scoped beans. Flash scopes are like the view scopes that will live on a specified view, including the redirects, and will be removed if you’re moving another view.
   • Navigation
     In JSF 1.x every navigation rule should be added to faces-config.xml. With version 2.0 implicit navigation can also be used, as in whether or not an outcome corresponds to a view I.D. It’s also possible to perform conditional navigations on a navigation-case. The new tag <if> can be used in faces-config, with an el snippet for conditional navigation. Version 2.0 also makes it easy to retrieve view parameters and assign them to a given property, which in turn makes handling the parameters for GET requests easy. Two new components (h:link and h:button) also support the integration of view parameters. The key benefit of using these components will be bookmarkable URLs.
   • Configuration with Annotations
     With JSF 2.0 you can annotate your managed beans with the new @ManagedBean annotation, and you can specify the scope for your beans with @RequestScoped, @SessionScoped, @ViewScoped, @NoneScoped and more. Instead of those, we’ve chosen to use CDI and Weld annotations.
7. Common Annotations for Java Platform (JSR-250) 1.1
8. Enterprise JavaBeans (EJB) 3.1 Lite
9. Java Transaction API (JTA) 1.1
10. Java Persistence API (JPA) 2.0
    In our opinion, the main highlights of this release are the API for criteria queries and the support for validation. There are also some fancy new features like extended map support and ordered list mappings.

Java EE 6 Containers

There are currently two application servers that are compatible with the implementation of Java EE 6: GlassFish Enterprise Server v3 and TMAX JEUS 7. We’ve chosen to stick with GlassFish v3.

So – What’s Up with PrimeFaces?

PrimeFaces is an open source JSF component suite that bundles over 70 components with built-in Ajax support. It’s based on the YUI and jQuery javascripting libraries. It has a simple, lightweight design that is fully compatible with other JSF component libraries. PrimeFaces also supports Ajax Push with a Comet framework, and it has a mobile UI kit known as TouchFaces. Currently, PrimeFaces supports JSF 2.0 with its 2.0.0.RC and 2.0.0-SNAPSHOT releases.

The ability of Java EE 6 to merge web.xml fragments that originate from third-party frameworks makes it unnecessary (in the context of Java EE 6) to do servlet and mapping configurations for PrimeFaces. Primefaces ships with its own web-fragment.xml.

For more information, visit www.primefaces.org.

Contexts and Dependency Injection (CDI)

As stated in Java Specification Request JSR-299, the purpose of this specification is to unify the JSF-managed bean component model with the EJB component model, resulting in a significantly simplified programming model for web-based applications. CDI also makes it possible for JEE elements to interact with each other using the observer pattern, making it a lot easier to work with enterprise beans and transactional support, among other things.

Dependency Injection For Java

JSR 330 is also a part of Java EE 6, offering a set of standard annotations that can be used for dependency injection. In our demo application we’ll use some of these annotations, such as @Named, @Inject, @Qualifier and others.

WELD

Weld is the reference implementation of JSR-299, which is abbreviated as CDI.  Weld provides a complete SPI, allowing Java EE containers to use Weld as their built-in CDI implementation. GlassFish 3 (which we’ll use in our demo) ships with Weld.

Bean Validation and Hibernate Validator

The Bean Validation, JSR 303, defines a metadata model and an API for JavaBean validation. The Hibernate Validator is the reference implementation for this specification request. Hibernate Validator’s latest version adds some nice features — things like validation grouping, native integration with JPA v.2 and JSF v.2, an extended annotation set and more.

WallFriend, The Demo APP

Let’s start by creating the project. We’ll do it using the Maven archetype command. It has an interactive mode, so see below for the user input data (in bold).

mvn archetype:generate -DarchetypeCatalog=http://anonsvn.jboss.org
   /repos/weld/archetypes/tags/1.0.0-BETA1

DEV$ mvn archetype:generate -DarchetypeCatalog=http://anonsvn.jboss.org
   /repos/weld/archetypes/tags/1.0.0-BETA1
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] ------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO]    task-segment: [archetype:generate] (aggregator-style)
[INFO] ------------------------------------------------------------------
[INFO] Preparing archetype:generate
[INFO] No goals needed for project - skipping
[INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [archetype:generate]
[INFO] Generating project in Interactive mode
[INFO] No archetype defined. Using maven-archetype-quickstart
(org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
1: remote -> weld-jsf-servlet-minimal (Weld archetype for creating an
application using JSF 2.0 and CDI 1.0 for Servlet Containers
(Tomcat 6 / Jetty 6))
2: remote -> weld-jsf-jee-minimal (Weld archetype for creating a minimal
Java EE 6 application using JSF 2.0, CDI 1.0 and EJB 3.1 (persistence unit
not included))
3: remote -> weld-jsf-jee (Weld 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))
Choose a number:  (1/2/3): 2

Here enter 2, for weld-jsf-jee-minimal. And then specify the
groupId-artifactId-packaging for the project.

Define value for groupId: : com.openlogic.wazi
Define value for artifactId: : wallfriend
Define value for package: : war
Confirm properties configuration:
version: 1.0.0-SNAPSHOT
groupId: com.openlogic.wazi
artifactId: wallfriend
package: war
 Y: : Y
[INFO] -------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] -------------------------------------------------------------------
[INFO] Total time: 19 seconds
[INFO] Finished at: Tue Jan 12 21:58:35 EET 2010 [INFO]
Final Memory: 12M/79M [INFO]
-------------------------------------------------------------------

Since this is an archetype project, we can immediately run it from the command line with Maven on an embedded GlassFish:

DEV$ mvn package embedded-glassfish:run
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'embedded-glassfish'.
[INFO] org.apache.maven.plugins: checking for updates from glassfish
[INFO] org.codehaus.mojo: checking for updates from glassfish
[INFO] -------------------------------------------------------------------
[INFO] Building wallfriend
[INFO]    task-segment: [package, embedded-glassfish:run]
[INFO] -------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 1 source file to /DEV/wallfriend/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to /DEV/wallfriend/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory: /DEV/wallfriend/target/surefire-reports

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running TestSuite
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.369 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO] [war:war]
[INFO] Packaging webapp
[INFO] Assembling webapp[wallfriend] in [/DEV/wallfriend/target/wallfriend]
[INFO] Processing war project
[INFO] Webapp assembled in[162 msecs]
[INFO] Building war: /DEV/wallfriend/target/wallfriend.war
[INFO] [embedded-glassfish:run]
[WARNING] Attempting to build MavenProject instance for Artifact
(org.codehaus.mojo:jboss-maven-plugin:3.0) of type: maven-plugin;
constructing POM artifact instead.
Downloading: http://repository.jboss.org/maven2/org/codehaus/mojo
/jboss-maven-plugin/3.0/jboss-maven-plugin-3.0.pom
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo
/jboss-maven-plugin/3.0/jboss-maven-plugin-3.0.pom
[WARNING] Attempting to build MavenProject instance for Artifact
(org.apache.maven.plugins:maven-eclipse-plugin:3.0)  of type:
maven-plugin; constructing POM artifact instead.
Downloading: http://repository.jboss.org/maven2/org/apache/maven
/plugins/maven-eclipse-plugin/3.0/maven-eclipse-plugin-3.0.pom
Downloading: http://repo1.maven.org/maven2/org/apache/maven
/plugins/maven-eclipse-plugin/3.0/maven-eclipse-plugin-3.0.pom
Jan 13, 2010 10:36:39 PM com.sun.enterprise.v3.server.AppServerStartup run
INFO: GlassFish v3 (74.2) startup time : Embedded(1228ms)
startup services(1317ms) total(2545ms)
Jan 13, 2010 10:36:39 PM com.sun.enterprise.transaction
.JavaEETransactionManagerSimplified initDelegates
INFO: Using com.sun.enterprise.transaction.jts
.JavaEETransactionManagerJTSDelegate as the delegate
Jan 13, 2010 10:36:40 PM org.glassfish.admin.mbeanserver
.JMXStartupService$JMXConnectorsStarterThread run
INFO: JMXStartupService: JMXConnector system is disabled, skipping.
Jan 13, 2010 10:36:40 PM AppServerStartup run
INFO: [Thread[GlassFish Kernel Main Thread,5,main]] started
Jan 13, 2010 10:36:40 PM org.hibernate.validator.util.Version
INFO: Hibernate Validator null
Jan 13, 2010 10:36:40 PM org.hibernate.validator.engine.resolver
.DefaultTraversableResolver detectJPA
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver
.JPATraversableResolver.
Jan 13, 2010 10:36:41 PM com.sun.enterprise.v3.services.impl
.GrizzlyProxy$2$1 onReady
INFO: Grizzly Framework 1.9.18-k started in: 434ms listening on port 7070
Jan 13, 2010 10:36:58 PM com.sun.common.util.logging
.LoggingConfigImpl openPropFile
INFO: Cannot read logging.properties file.
Jan 13, 2010 10:36:58 PM com.sun.enterprise.web.WebContainer
createHttpListener
INFO: Created HTTP listener embedded-listener on port 7070
Jan 13, 2010 10:36:58 PM com.sun.enterprise.web.WebContainer
configureHttpServiceProperties
WARNING: pewebcontainer.invalid_http_service_property
Jan 13, 2010 10:36:59 PM com.sun.enterprise.web.WebContainer createHosts
INFO: Created virtual server server
Jan 13, 2010 10:36:59 PM com.sun.enterprise.web.WebContainer
loadSystemDefaultWebModules
INFO: Virtual server server loaded system default web module
^[[BJan 13, 2010 10:37:08 PM com.sun.enterprise.security.SecurityLifecycle
INFO: security.secmgroff
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.ssl.SSLUtils
checkCertificateDates
SEVERE: java_security.expired_certificate
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.SecurityLifecycle
onInitialization
INFO: Security startup service called
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.PolicyLoader
loadPolicy
INFO: policy.loading
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.auth.realm.Realm
doInstantiate
INFO: Realm admin-realm of classtype com.sun.enterprise.security.auth
.realm.file.FileRealm successfully created.
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.auth.realm.Realm
doInstantiate
INFO: Realm file of classtype com.sun.enterprise.security.auth.realm.file
.FileRealm successfully created.
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.auth.realm.Realm
doInstantiate
INFO: Realm certificate of classtype com.sun.enterprise.security.auth
.realm.certificate.CertificateRealm successfully created.
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.SecurityLifecycle
onInitialization
INFO: Security service(s) started successfully....
classLoader = WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7@2d205042
Jan 13, 2010 10:37:09 PM org.jboss.weld.bootstrap.WeldBootstrap
INFO: WELD-000900 SNAPSHOT
Jan 13, 2010 10:37:09 PM org.hibernate.validator.engine.resolver
.DefaultTraversableResolver detectJPA
INFO: Instantiated an instance of org.hibernate.validator.engine
.resolver.JPATraversableResolver.
nullID: /DEV/wallfriend/gfembed6764346819525137279tmp/applications
/wallfriend/ CLASSES: [class war.HelloWorld]

Jan 13, 2010 10:37:10 PM com.sun.faces.config.ConfigureListener
contextInitialized
INFO: Initializing Mojarra 2.0.2 (FCS b10) for context '/wallfriend'
Jan 13, 2010 10:37:14 PM com.sun.enterprise.web.WebApplication start
INFO: Loading application wallfriend at /wallfriend
Hit ENTER to redeploy, X to exit

Once you see the line Hit ENTER to redeploy, X to exit, make a request for http://localhost:7070/wallfriend on your browser. You should get a first look at the archetype application like the one below:

Now, let’s open the project inside NetBeans 6.8. Open NetBeans and click File > New Project and then select Maven / Maven Project with Existing POM from the resulting wizard. This should put the Open Project menu on your screen. Select wallfriend from here and you should see the project in the projects tab:

To run wallfriend inside NetBeans 6.8, you need to make sure that you have Java 1.6 defined as a Java platform, and be sure that wallfriend is also using it. Also, from the Tools > Servers menu, you need to define the Java 1.6 executable for your GlassFish. Netbeans also comes with a Maven 3.0-SNAPSHOT version. So, if you want to use your own external Maven, you must declare it to the IDE from Preferences > Miscellaneous > Maven. After configuring it all, just make a request for http://localhost:8080/wallfriend on your browser. You should see the very same page as you did when you ran the project with the embedded GlassFish.

Adding PrimeFaces to the Project

In order to use the JSF components of PrimeFaces, we first have to add the repo and dependency definitions to the pom.xml of the project. Go ahead and open Project Files > pom.xml in NetBeans and add the following snippets, respectively:

<repository>
    <id>prime-repo</id>
    <name>Prime Technology Maven Repository</name>
    <url>http://repository.prime.com.tr</url>
    <layout>default</layout>
</repository>

<dependency>
    <groupId>org.primefaces</groupId>
    <artifactId>primefaces</artifactId>
    <version>2.0.0-SNAPSHOT</version>
</dependency>

Now namespace can be added inside the xhtml’s files for PrimeFaces, xmlns:p=”http://primefaces.prime.com.tr/ui”. As mentioned above, there is no configuration needed in web.xml since PrimeFaces ships with its own web fragment.

Wallfriend – The Implementation

As we said before, wallfriend is a simple write-to-wall application with a basic domain, managed beans, and some xhtml pages. You can check out the source from the Google Code project at http://wallfriend.googlecode.com/svn/trunk/wallfriend. A follow the wall mechanism as well as a restful expose of the wall will be added to the project in the near future.

Since the application was not created from scratch, we have some clean-up to do on the archetype-created application. Go ahead and delete the following folders, because they won’t be used:

• Web Pages/WEB-INF/templates
• Web Pages/resources
• Source Packages / war
• Test packages / war

Now let’s go through the parts of the project: The Model, The Managed Beans, and The Views.

The Model

For the domain, we have 3 classes: Wall, Brick and WallFriendContext. Wall and Brick are for defining a master-detail relationship between the posts and the wall. WallFriendContext is the application-scoped bean for storing created walls. It’s marked with the javax.enterprise.context.ApplicationScoped bean.

Wall.java

package com.openlogic.wazi.beans;

import java.util.LinkedList;
import java.util.List;

public class Wall {

    String wallName;

    List bricks = new LinkedList();

    public Wall(String wallName) {
        this.wallName = wallName;
    }

    public void addBrick(String graffiti) {
        bricks.add(0, new Brick(graffiti));
    }

    public String getWallName() {
        return wallName;
    }

    public List getBricks() {
        return bricks;
    }
}

Brick.java

package com.openlogic.wazi.beans;

import java.util.Date;

public class Brick {

    private String graffiti;
    private Date publishDate;

    public Brick(String graffiti) {
        this.graffiti = graffiti;
        this.publishDate = new Date();
    }

    public void init() {
    }

    public String getGraffiti() {
        return graffiti;
    }

    public void setGraffiti(String graffiti) {
        this.graffiti = graffiti;
    }

    public Date getPublishDate() {
        return publishDate;
    }

    public void setPublishDate(Date publishDate) {
        this.publishDate = publishDate;
    }
}

WallFriendContext.java

package com.openlogic.wazi.beans;

import java.util.HashMap;
import java.util.Map;
import javax.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class WallFriendContext {

    private Map walls = new HashMap();

    public void addWall(Wall wall) {
        walls.put(wall.getWallName(), wall);
    }

    public Map getWalls() {
        return walls;
    }
}

The Managed Beans (a.k.a. Contextual Beans)

The managed bean classes are defined by the CDI and implemented by Weld, which ships with the GlassFish server. CDI also needs an empty beans.xml file under the WEB-INF folder, since we’re going to use annotations to define our beans. That’s right — that means they can also be configured with good old fashioned XML.

LoginView is the managed bean of choice for handling wall management and creation/accessing. The annotation javax.enterprise.inject.Model identifies the LoginView as a bean of the model layer, as stated in the MVC pattern. We use javax.inject.Inject to identify injectable constructors, while methods and fields. org.hibernate.validator.constraints.NotEmpty is a validator annotation that specifies that the field wallName cannot be empty.

package com.openlogic.wazi.view;

import com.openlogic.wazi.beans.Wall;
import com.openlogic.wazi.beans.WallFriendContext;
import javax.enterprise.inject.Model;
import javax.faces.context.FacesContext;
import javax.inject.Inject;
import org.hibernate.validator.constraints.NotEmpty;

@Model
public class LoginView {

    @Inject
    private WallFriendContext wallFriendContext;

    @NotEmpty(message="Wall Name cannot be empty")
    private String wallName;

    public String doLogin() {
        Wall wall;
        if (wallFriendContext.getWalls().containsKey(wallName)) {
            wall = wallFriendContext.getWalls().get(wallName);
        }
        else {
            wall = new Wall(wallName);
            wallFriendContext.addWall(wall);
        }
        FacesContext.getCurrentInstance().getExternalContext()
.getRequestMap().put("wall", wall);

        return "myWall";
    }

    public String getWallName() {
        return wallName;
    }

    public void setWallName(String wallName) {
        this.wallName = wallName;
    }
}

MyWallView is the managed bean for handling the paint-a-graffiti on the wall action. The annotation javax.inject.Named, used here, allows you to access the bean using the bean name, with the first letter in lowercase. We use javax.annotation.PostConstruct to mark a method to be invoked after the Dependency Injection is done.

package com.openlogic.wazi.view;

import com.openlogic.wazi.beans.Wall;
import java.io.Serializable;
import javax.annotation.PostConstruct;
import javax.enterprise.context.SessionScoped;
import javax.faces.context.FacesContext;
import javax.inject.Named;
import org.hibernate.validator.constraints.NotEmpty;

@Named
@SessionScoped
public class MyWallView implements Serializable {

    private Wall wall;

    @PostConstruct
    public void init() {
        wall = (Wall) FacesContext.getCurrentInstance()
                  .getExternalContext().getRequestMap().get("wall");
    }

    @NotEmpty(message="Graffiti cannot be empty")
    private String graffiti;

    public String paint() {
        wall.addBrick(graffiti);
        graffiti = "";

        return null;
    }

    public Wall getWall() {
        return wall;
    }

    public void setWall(Wall wall) {
        this.wall = wall;
    }

    public String getGraffiti() {
        return graffiti;
    }

    public void setGraffiti(String graffiti) {
        this.graffiti = graffiti;
    }
}

The Pages

Facelets, JSF 2.0, and PrimeFaces projects are used for the development of views. JSF tags are also commonly used. One different component could be p:growl, which is for viewing the FacesMessages in a Mac-like growl. Also, there is no defined navigation-rule in the faces-config.xml file for navigating from login.xhtml to myWall.xhtml. This is with the implicit navigation mechanism that comes with JSF 2.0. The return string of LoginView#doLogin() method matches the name of the myWall.xhtml view.

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
     xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:p="http://primefaces.prime.com.tr/ui">
      <h:head>
          <title>WallFriend - Java EE 6 Starter Application</title>
      </h:head>
      <h:body>
          <h:form>
              <p:growl showDetail="true" />
              <p:panel header="Access to your wall" style="width:400px">
                  <h:outputLabel value="Wall Name : " for="wallname" />
                  <h:inputText id="wallname" value="#{loginView.wallName}" />
                  <h:commandButton value="Paint it Now, Paint it Black"
                      action="#{loginView.doLogin}" />
              </p:panel>
          </h:form>
      </h:body>
</html>

myWall.xhtml page renders the wall posts for a wall, and the user can also write up to the wall.

 <html xmlns="http://www.w3.org/1999/xhtml"
       xmlns:h="http://java.sun.com/jsf/html"
       xmlns:f="http://java.sun.com/jsf/core"
       xmlns:ui="http://java.sun.com/jsf/facelets"
       xmlns:p="http://primefaces.prime.com.tr/ui">
       <h:head>
          <title>WallFriend - Java EE 6 Starter Application</title>
       </h:head>
       <h:body>
          <h:form>
             <p:growl showDetail="true" />
                <p:panel header="#{myWallView.wall.wallName}'s WALL"
                    style="width:600px">
                   <h:panelGrid columns="1">
                   <h:panelGroup>
                      <h:inputTextarea value="#{myWallView.graffiti}"
                             cols="50" rows="3" />
                      <h:commandButton value="Paint"
                             action="#{myWallView.paint}" />
                   </h:panelGroup>
                   <p:dataTable value="#{myWallView.wall.bricks}"
                            var="brick">
                      <p:column>
                        #{brick.graffiti}
                        <br/>
                        <h:outputText value="#{brick.publishDate}">
                           <f:convertDateTime dateStyle="default"
                              type="both" pattern="dd.MM.yyyy HH:mm:ss" />
                        </h:outputText>
                     </p:column>
                  </p:dataTable>
               </h:panelGrid>
            </p:panel>
         </h:form>
      </h:body>
</html>

Finishing Up

Java EE 6 is hot, new, and pretty darn cool. In our opinion, as users begin to employ it for upcoming projects, the number of blogposts, samples, and other resources will eventually increase. And with its adoption by the Java Community, we’ll for sure see more Java EE 6-compliant application servers around. Java EE 6 really eases development with its “standardized” features, and the zero-configuration approach apparent in every part of the implementation is really nice, lending an out-of-the-box feeling that’s similar to the .NET environment.  It’s not just another java framework!