The JPA 2 metamodel is the cornerstone of type-safe criteria queries in JPA 2. The generated classes allow you to refer to entity properties using static field references, instead of strings. (A metamodel class is the fully-qualified class name of the entity class it matches followed by an underscore (_)).

It sounds promising, but many people using Maven are getting tripped up trying to get the metamodel generated and compiled. The Hibernate JPA 2 Metamodel Generator guide offers a couple of solutions. I've figured out another, which seems more elegant.

Just to refresh your memory of the problem:

1. Maven compiles the classes during the compile phase
2. The Java 6 compiler allows annotation processors to hook into it
3. Annotation processors are permitted to generate Java source files (which is the case with the JPA 2 metamodel)
4. Maven does not execute a secondary compile step to compile Java source files generated by the annotation processor

I figured out that it's possible to use the Maven compiler plugin to run only the annotation processors during the generate-sources phase! This effectively becomes a code generation step. Then comes the only downside. If you can believe it, Maven does not have a built-in way to compile generated sources. So we have to add one more plugin (build-helper-maven-plugin) that simply adds an additional source folder (I really can't believe the compiler plugin doesn't offer this feature). During the compile phase, we can disable the annotation processors to speed up compilation and avoid generating the metamodel a second time.

Here's the configuration for your copy-paste pleasure. Add it to the <plugins> section of your POM.

<!-- Compiler plugin enforces Java 1.6 compatibility and controls execution of annotation processors -->
<plugin>
   <artifactId>maven-compiler-plugin</artifactId>
   <version>2.3.1</version>
   <configuration>
      <source>1.6</source>
      <target>1.6</target>
      <compilerArgument>-proc:none</compilerArgument>
   </configuration>
   <executions>
      <execution>
         <id>run-annotation-processors-only</id>
         <phase>generate-sources</phase>
         <configuration>
            <compilerArgument>-proc:only</compilerArgument>
            <!-- If your app has multiple packages, use this include filter to
                 execute the processor only on the package containing your entities -->
            <!--
            <includes>
               <include>**/model/*.java</include>
            </includes>
            -->
         </configuration>
         <goals>
            <goal>compile</goal>
         </goals>
      </execution>
   </executions>  
</plugin>         
<!-- Build helper plugin adds the sources generated by the JPA 2 annotation processor to the compile path -->
<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>build-helper-maven-plugin</artifactId>
   <version>1.5</version>
   <executions>      
      <execution> 
         <phase>process-sources</phase>
         <configuration>
            <sources>
               <source>${project.build.directory}/generated-sources/annotations</source>
            </sources>
         </configuration>
         <goals>
            <goal>add-source</goal>
         </goals>
      </execution>
   </executions>
</plugin>

The metamodel source files get generated into the target/generated-sources/annotations directory.

Note that if you have references to the metamodel across Java packages, you'll need to filter the annotation processor to only run on the package containing the entity classes.

We'll be protoyping this approach in the 1.0.1.Beta1 release of the Weld archetypes, which should be out soon.

Bonus material: Eclipse configuration

While I'm at it, I might as well show you how I enabled the JPA 2 metamodel generation in Eclipse. (Max may correct me. He's the authority on Eclipse tooling, so listen to what he says).

Start by adding the following dependency to your POM:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-jpamodelgen</artifactId>
   <version>1.0.0.Final</version>
   <scope>provided</scope>
</dependency>

Then, populate the .factorypath file at the root of your project with the following contents:

<factorypath>
    <factorypathentry kind="PLUGIN" id="org.eclipse.jst.ws.annotations.core" enabled="true" runInBatchMode="false"/>
    <factorypathentry kind="VARJAR" id="M2_REPO/org/hibernate/hibernate-jpamodelgen/1.0.0.Final/hibernate-jpamodelgen-1.0.0.Final.jar" enabled="true" runInBatchMode="false"/>
    <factorypathentry kind="VARJAR" id="M2_REPO/org/hibernate/javax/persistence/hibernate-jpa-2.0-api/1.0.0.Final/hibernate-jpa-2.0-api-1.0.0.Final.jar" enabled="true" runInBatchMode="false"/>
</factorypath>

Refresh the project in Eclipse. Now right click on the project and select:

Properties > Java Compiler > Annotation Processing

Enable project specific settings and enable annotation processing. Press OK and OK again when prompted to build the project. Now, Eclipse should also generate your JPA 2 metamodel.

Happy type-safe criteria querying!

Cool software projects have cool logos. We recently announced an alpha release of Arquillian, a project that's going to revolutionize Java EE integration testing. Now we need to make Arquillian cool :)

We are in the process of establishing Arquillian's visual identity, its logo. We've already been through a couple rounds of grayscale design comps with Cheyenne from the JBoss Community design team, who is designing the Arquillian logo. Throughout the process, we've asked community members to provide feedback on the comps to help steer the design process. You can follow some of the progress in this thread or the #arquillian Twitter hashtag. We're casting a wider net this time by asking readers of this blog to chime in.

The themes we are pursuing are:

• aliens
• remote control
• in container

Here are the round 3 logo candidates:

Follow the link to the poll below to let us know which ones you like best and why.

Arquillian logo poll (Round 3)

Once we collect enough feedback, we'll send it over to Cheyenne and let you know which ones made the cut. Thanks for participating!

As promised, we're happy to announce another early release of a Seam 3 module, Seam XML 3.0.0 Alpha 1. The Seam XML module, contributed and led by Stuart Douglas, is a CDI portable extension that allows you to add, modify and extend CDI-discovered beans using XML as an alternative to annotations.

But not just any XML. It's a typesafe XML format heavily based on an early revision of the JSR-299 (then Web Beans) specification.

Try it on for size

Let's assume you have defined the following ProducerBean class:

package org.jboss.seam.xml.test.injection;

public class ProducerBean {
   private String message = "Hello, annotation fans!";
}

and the following qualifier annotation:

package org.jboss.seam.xml.test.injection;

@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface ProducerQualifer {}

You want to expose the message field of ProducerBean using a CDI producer. You could take an annotation approach:

package org.jboss.seam.xml.test.injection;

public class ProducerBean {
   @Produces
   @ProducerQualifier
   private String message = "Hello, annotation fans!";
}

But what if the class isn't under your control, or you are more of a fan of XML tag soup? You can apply the same bean metadata using XML:

<test:ProducerBean>
   <test:message>
      <s:Produces/>
      <test:ProducerQualifier/>
      <s:value>Hello, XML fans!</s:value>
   </test:message>
</test:ProducerBean>

That snippet may take a while for your mind to parse, but observe closely how the XML tags map to the annotated version of the ProducerBean class. Notice we've also overridden the value of the message field in XML to say Hello, XML fans! rather than Hello, annotation fans! Assigning field values in XML is a very useful feature which cannot (easily) be addressed with annotations alone.

What's with all the namespace prefixes? The namespace prefix s is for the Seam XML schema and test represents the Java package of the bean class being configured. Here's the complete configuration file with the XML root and namespace declarations included. Also notice that an additional bean is being configured, ReceiverBean, this one through metadata extension.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:s="urn:java:seam:core"
   xmlns:test="urn:java:org.jboss.seam.xml.test.injection">

   <test:ProducerBean>
      <s:override/>
      <test:message>
         <s:Produces/>
         <test:ProducerQualifier/>
         <s:value>Hello, XML fans!</s:value>
      </test:message>
   </test:ProducerBean>

   <test:RecieverBean>
      <s:extends/>
      <test:anotherField>
         <test:ProducerQualifier/>
         <s:Inject/>
      </test:anotherField>
   </test:RecieverBean>

</beans>

To give you the complete picture, this example wires up two beans, a bean with a producer field that produces Hello, XML fans! and a bean that injects the produced value. The ProducerBean overrides the existing bean, while RecieverBean extends the existing bean, so annotations physically present on the class will be merged with those defined in the XML file. For more information please consult the docs and exmaple that are bundled with the distribution.

Rev up your XML editor!

Now that you've seen a glimpse of what this module offers, it's time to go get it. Here are the links you need to get started.

• Download
• Reference Guide
• Issue Tracker

As with all Seam 3 modules releases, the Seam XML module is published to the central Maven 2 repository. Here's the dependency declaration you need to add to your POM to include this module in your project (note the hyphen in the version):

<dependency>
   <groupId>org.jboss.seam.xml</groupId>
   <artifactId>seam-xml-core</artifactId>
   <version>3.0.0-Alpha1</version>
</dependency>

As this is an early release, there is no guarentee that the syntax is set in stone. It all depends on your feedback, which we are very interested in receiving!

Please join us!

We are hoping that all JSR-299 implementations can join us in our effort to get XML configuration into the next version of the spec. You can help by adopting this XML schema and helping us to define, refine and improve on it.

A tremendous thanks to Stuart Douglas for putting this module together. The XML configuration lays a key foundation for the entire Seam 3 project! Also thanks to Shane Bryzak for preparing the release.

Stay tuned for alpha releases of additional Seam modules in the near future, such as Seam International (i18n), which will give you enhanced language support for Java EE 6 applications, and Seam Faces, an appetizing collection of extensions and enhancements for JSF 2. Keep in mind that everything is on the drafting table right now. Join us!

I'm often asked to identify what projects I'm working on at Red Hat, or what group I'm a part of. My response reads like a laundry list:

• Seam
• Weld
• CDI TCK
• Arquillian

...and sometimes I'm really not sure if I can classify myself as a member of a certain project (e.g., RichFaces). Other developers that hang around here likely have a similar story. Eventually, we just settle on the response, I'm part of the in.relation.to crowd.

However, for people that don't know this blog, or its history, this description makes no sense whatsoever. Which made me come to the realization that we lack a true identity within the JBoss Community. I believe this detracts from the spirit of integration and coordination between projects. As my first order as Community Liaison, I set out to fix that.

Seam is often described as the glue that brings together a myriad of standard and third-party Java EE technologies. The glue that brings us together is that we are all working on creating tools and frameworks for the application developer (some use the term enterprise web developer). This purpose not only unites those of us creating these technologies, but also unites us with the folks that consume these technologies. So, to align the name of our group with the common organizational group name of our community members, we have chosen this name for our group:

Application Developer Projects Group (or the more casual name, App Dev Group)

This group is a loose knit collection of projects which people often view as their development stack:

• Seam
• JBoss Tools
• Weld (CDI)
• RichFaces (JSF)
• Hibernate Validator (Bean Validation)
• Hibernate (JPA)
• Hibernate Search
• ...perhaps others

We also recently formed the JBoss Testing Group that encompasses Arquillian, ShrinkWrap, JSFUnit, and other testing tools. Some of us are a part of that group too, myself included.

When we address this audience, or seek to describe where we fit in the JBoss community, we can really establish the connectedness by using the term App Dev, or Application Developer Projects, to show we are thinking about the concerns across technologies. So there you have it, our group name.

The JSF 2 series on DZone we've been working on continues with an introduction to JSF 2 client behaviors by guest author Andy Schwartz. Andy is a member of the JSR-314 Expert Group (EG) and architect on the ADF Faces project team at Oracle Corporation.

In this installment, Andy introduces you to client behaviors for UI components, an API which he led, in collaboration with Alex Smirmov (Exadel), Roger Kitain (Sun/Oracle) and Ted Goddard (ICEsoft), to provide a general extension point for adding client-side functionality (i.e., JavaScript) to existing UI components. This new API quickly received support and input from the entire EG and proved to be a solid foundation on which the declarative Ajax control (i.e., <f:ajax>) could be based.

One of the goals of providing an extensible API is to encourage JSF users to leverage this for their own needs. While we only have a single standard behavior (<f:ajax>) today, we expect to see many third party behavior implementations in the near future. Some of these behaviors may be candidates for inclusion in future versions of the JSF specification – perhaps even yours!

We'd like to thank Andy for contributing his time and dedication in writing this article! Although Andy represents a different company than the other authors in this series, we come together as colleagues on the JSR-314 EG. The strong partnerships that are built between companies through their participation in JSRs are what make the JCP an asset to the Java EE community and allow the technologies to take such large leaps, in this case JSF. You can thank him too by rating the article.