In this blog entry I want to give you an impression of an alternative solution by agimatec, that is slightly different. It is the solution we are using in our products for more than two years and with which we are satisfied. It would be interesting to hear your options on this.

The concept

Database:

We generate history tables for each table for which we need auditing. We generate database triggers (oracle or postgres) to automatically insert data in the history tables when entities are stored/deleted.

We do not store duplicate data, which means that our history tables contain only OLD data. All current data is ONLY stored in the application’s tables (usually mapped by hibernate/Ejb3).

Configuration:

We have a XML configuration, that contains the table names for which we want to enable our history solution. This configuration lets you specify:

• name of history table (or a default name will be used)
• which columns to exclude from history (default is that all columns are historised)
• optionally you can turn off history for insert and/or update, change trigger names etc.

The XML configuration controls the tables and triggers generated by freemarker templates.

Features:

It is not only important to version the changes, but also to store, the timestamp of a change and some context information about the change (e.g. who is the actor, which application, from which sessionID etc.). Any context information can be associated with a version record by storing a contextID in the history table’s rows.

This is also a way to separate changes from user-specific data, which might be a judical requirement. An extended Hibernate event handler stores the contextID into the database session by calling a stored procedure, so that the history triggers and access the contextID to store it together with the history data.

Each history table has additional columns:

• HIST_TIME (timestamp of change)
• HIST_CONTEXTID (ID of context providing additional information)
• HIST_TYPE (to distinguish INSERT, UPDATE and DELETION)

A simple java API exists to query historical data. It returns the same classes as you use for your hibernate entities, but it materializes the objects itself. Hibernate does not know anything about the history tables or mappings.

The benefits

There are some differences between the solution provided by Envers and agimatec:

• Envers needs a global _revision table, agimatec’s history rows are identified by the primary key and a version number (@Version) incremented from 1 for each entity/no global _revision
• You can change data with any SQL tool.Historisation does not rely on hibernate as the only API to change the database.
• Whenever you increment a row’s version, the history triggers will automatically write historical data. By this way, you can use migration scripts that can control whether history data will be stored.
• Envers stores current data in history tables, which makes it a bit easier to query the data, but with means redundancy (and potential data inconsistencies).
• Both framework are integrated with Hibernate by extending the Hibernate Events (to provide context information).

Examples

History configuration

<historyConfig>
<tableConfig>
<tableName>booking</tableName>
</tableConfig>
<tableConfig>
<tableName>customer</tableName>
<historyTable>h_cust</historyTable>
<insertTrigger>TR_I_cust</insertTrigger>
<updateTrigger>TR_U_cust</updateTrigger>
</tableConfig>


Generated tables

CREATE TABLE H_JOURNAL (
ID INTEGER NOT NULL,
HIST_TABLE VARCHAR(50) NOT NULL,
HIST_TIME TIMESTAMP NOT NULL,
HIST_CONTEXTID VARCHAR(40),
CONSTRAINT H_JOURNAL_PK PRIMARY KEY (ID, HIST_TABLE)
);

CREATE TABLE H_booking (
VERSION INTEGER NOT NULL,
booking_id INTEGER NOT NULL,
price NUMBER,
HIST_TIME TIMESTAMP NOT NULL,
HIST_CONTEXTID VARCHAR(40),
HIST_TYPE CHAR(1) NOT NULL,
CONSTRAINT H_booking_PK PRIMARY KEY (VERSION, booking_id)
);
CREATE TABLE H_cust (
VERSION INTEGER NOT NULL,
cust_id INTEGER NOT NULL,
first_name VARCHAR2(40),
last_name VARCHAR2(40),
HIST_TIME TIMESTAMP NOT NULL,
HIST_CONTEXTID VARCHAR(40),
HIST_TYPE CHAR(1) NOT NULL,
CONSTRAINT H_cust_PK PRIMARY KEY (VERSION, card_id)
);

Generated triggers

CREATE OR REPLACE TRIGGER TR_I_cust
AFTER INSERT ON customer
REFERENCING NEW AS NEW
FOR EACH ROW
BEGIN
setTATime();
INSERT INTO H_JOURNAL (ID, HIST_TIME, HIST_CONTEXTID, HIST_TABLE)
select :NEW.card_id, h.ts, h_session.getContextId, 'customer' from h_tatime h;
END;
/

CREATE OR REPLACE TRIGGER TR_U_cust
AFTER DELETE OR UPDATE
ON customer
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
IF(DELETING) THEN
setTATime();
INSERT INTO H_cust (
cust_id,
version,
first_name,
last_name,
HIST_TIME, HIST_CONTEXTID, HIST_TYPE)
select
:OLD.cust_id,
:OLD.version,
:OLD.first_name,
:OLD.last_name,
h.ts, h_session.getContextId, 'D' from h_tatime h;
ELSIF (UPDATING AND :OLD.VERSION != :NEW.VERSION) THEN
setTATime();
INSERT INTO H_cust (
cust_id,
version,
first_name,
last_name,
HIST_TIME, HIST_CONTEXTID, HIST_TYPE)
select
:OLD.cust_id,
:OLD.version,
:OLD.first_name,
:OLD.last_name,
h.ts, h_session.getContextId, 'U' from h_tatime h;
END IF;
END;
/

Java API

The implementation of class HibernateHistoryReader was rather complex, because of the need to resolve the relationships through the current tables and the history tables. All changes done inside a single transaction are joined together by using a timestamp in HIST_TIME that is unique inside the running database transaction.

Here is interface HistoryReader:

interface HistoryReader {

void open(EntityManager entityManager);
void close();

List<EntityRevision> getRevisions(Class entityClass, Object primaryKey, Timeframe timeframe);
EntityRevision getRevision(Class entityClass, Object primaryKey, int version);

Map<Object, List<EntityRevision>> getChildrenRevisions(Class parentEntityClass,EntityRevision parentRevision,String relationship);

<E> HistoryEntity<E> loadEntity(Class<E> entityClass, Object primaryKey,Timestamp time);
<E> List<HistoryEntity<E>> loadChildren(Class parentEntityClass, String relationship,
Object parentPrimaryKey, Timestamp time);

}

Where class HistoryEntity contains the entity instance for a given point of time and some additional information, such as the contextID and the foreignKey values to load some to-one-references.

If you are interested in more details contact us.

Maven is a good tool to handle your dependencies. You shouldn’t copy the necessary artifacts by hand in your lib folder. It is the beginning of the end for your project. Transitive dependencies could ease the management of your dependencies and Maven is the right tool for this. But sometimes it is to much magic behind the scenes. There could be a lot of transitive dependencies and there could be conflicts. Even more if your projects gets larger and uses more and more open source frameworks. We had problems with two actions:

• Change the version of a dependency
• Update the version of Maven

Change the version of a dependency

If you update the version of a dependency this could cause completely different transitive dependencies to be fetched. Normally no big deal, but you need to clean your artifacts. Often you just use mvn install to install your artifact. But without the clean target, the old dependencies are still in your target folder. Remember to use mvn clean install when changing the version of a dependency. But there is also another place, where old dependencies can survive. If you hot deploy your artifacts to your server, you should also delete the old artifacts and extracted folders. After that you are in a really clean condition.

Update the version of Maven

We had problems with transitive dependencies when changing the version of Maven. Make sure that every team member and build server uses the same version. Then you can still have problems, but there are no different transitive resolutions on different computers. Can be very confusing if one person in the team has version A and another one has version B. I think the Maven team tries to reduce this, but if there are changes in the dependency resolution, it could happen that conflicts are solved in a different way.

What about real trouble?

If you have a lot open source dependencies, there are much more transitive dependencies. Maven tries to resolve conflicts, but you will often find a situation, where dependencies A and B needs the same transitive dependency but in a different version. This can produce situations, described in the post: Maven supports JAR hell. Something is wrong and you have a lot of unwanted dependencies in your library folder. The next step is to find out, where they come from. This can be complicated, because transitive dependencies also have own transitive dependencies.

Find out where the dependencies come from

There are different solutions for this and Maven has improved the detection of dependencies for users. Most of the time I use the Maven site. It is always a good idea to use this feature, because it can give you a nice overview of your project. Take the time and configure your site, it is very helpful for the team.

To generate the Maven site just use: mvn site

This will generate a linked web site, where you can use a lot plugins. There is also the section dependencies, where you can have a look what dependencies exist and watch the transitive dependencies tree.

But there are also command line options. First of all the Maven Dependency Plugin. To get the transitive dependencies tree just type: mvn dependency:tree

It will display where the dependencies come from. It is also possible to filter the output or find conflicts.

We also use the concept of parent POMs with a deeper hierarchy. Sometimes you need to know, how your effective POM in the sub-project looks like. To get this information use: mvn help:effective-pom

You should have a look at the Maven Help Plugin, because there are some interesting other options.

Start your own dependency management

That doesn’t mean that you don’t use Maven. But most of the time you know your artifacts and their actual version. And you want a specific version to be included. You also want to have a consistent version of an artifact used through all sub-projects, then you can use declarative dependency management in Maven. That can avoid classpath issues. It is also very easy to upgrade a version, because the child-POMs don’t have a version included. They use the version defined in the parent POM.

We manage our dependencies in our master parent POM. There is a section in the XML called dependencyManagement. There you can list your dependencies and add the group, the artifactId and very important: the version. Now every time Maven tries to resolve a dependency it is using this specified version. Easy, isn’t it? Yes, the dependency management list is getting larger, but in a large project you are very pleased to find always the correct version of your dependencies.

Read more about this in the Maven documentation.

For us it was a great time saver, because we had less problems with Maven. You don’t need your own dependency management, but if you run in trouble think about using it.

If you want the know about the best Maven plugins, check out the Top 10 Maven plugins on our blog.

If you need more options you should have a look at Spring Security (formerly known as Acegi Security). There are a lot of options in Spring Security, but I will give you an example, not a list of features copied from the documentation.

Requirements

• easy configuration
• working together with Struts2
• URL based
• getting user details from a web service

When I started using Spring Security I found a lot of examples. There is also a good documentation available, but you need some hours to sort everything. Because I couldn’t find an example for exactly my problem, I will share my solution.

Before we start

At the beginning of your application you should plan which areas need a security layer. You don’t need to include it from the beginning, but please take the time to think about it. This will reduce the configuration time afterwards. If you know that some services will be secured, create a special namespace for this (e.g. /secure/*). For your URL based security you just need to include the namespace. It is a waste of time to create a lot of actions in a base folder and write 100 lines of suspect security configuration. If you forget an action, it could be very dangerous. If you need a more fine grained security you can use a good URL layout as a starting point and reduce the configuration overhead.

Let’s get real

Maven configuration

<project>

  ...

  <dependencies>
    <!--  Struts 2 -->
    <dependency>
      <groupId>org.apache.struts</groupId>
      <artifactId>struts2-core</artifactId>
    </dependency>
    <dependency>
      <groupId>org.apache.struts</groupId>
      <artifactId>struts2-sitemesh-plugin</artifactId>
    </dependency>
    <dependency>
      <groupId>org.apache.struts</groupId>
      <artifactId>struts2-spring-plugin</artifactId>
    </dependency>

    <!-- Security -->
    <dependency>
      <groupId>org.springframework.security</groupId>
      <artifactId>spring-security-core</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.security</groupId>
      <artifactId>spring-security-core-tiger</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.security</groupId>
      <artifactId>spring-security-acl</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.security</groupId>
      <artifactId>spring-security-taglibs</artifactId>
    </dependency>

    <!-- Servlet & Jsp -->
    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>servlet-api</artifactId>
      <version>2.4</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>jsp-api</artifactId>
      <version>2.0</version>
      <scope>provided</scope>
    </dependency>
</project>

web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
      http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
         version="2.4">
  <display-name>Name</display-name>

  <!-- path of applicationContexts used by spring -->
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
      /WEB-INF/applicationContext.xml
      /WEB-INF/applicationContext-security.xml
    </param-value>
  </context-param>

  <filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
  </filter>
  <filter>
    <filter-name>action2-cleanup</filter-name>
    <filter-class>org.apache.struts2.dispatcher.ActionContextCleanUp</filter-class>
  </filter>
  <filter>
    <filter-name>sitemesh</filter-name>
    <filter-class>com.opensymphony.module.sitemesh.filter.PageFilter</filter-class>
  </filter>
  <filter>
    <filter-name>action2</filter-name>
    <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
  </filter>

  <filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
  <filter-mapping>
    <filter-name>action2-cleanup</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
  <filter-mapping>
    <filter-name>sitemesh</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
  <filter-mapping>
    <filter-name>action2</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>

  <!-- Listeners -->
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>

  <!-- Welcome file lists -->
  <welcome-file-list>
    <welcome-file>index.jsp</welcome-file>
  </welcome-file-list>
</web-app>

applicationContext.xml

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="

http://www.springframework.org/schema/beans

           http://www.springframework.org/schema/beans/spring-beans-2.0.xsd" default-autowire="autodetect">

  <!-- UserService for Spring Security -->
  <bean id="customUserService" class="com.agimatec.ostium.security.CustomUserDetailsService"/>
</beans>

applicationContext-security.xml

<!--
- Spring namespace-based configuration
-->
<beans:beans xmlns="http://www.springframework.org/schema/security"
             xmlns:beans="http://www.springframework.org/schema/beans"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.0.xsd

http://www.springframework.org/schema/security

http://www.springframework.org/schema/security/spring-security-2.0.1.xsd">

  <!--
  - Secure the page per the URL pattern
  -->
  <http auto-config="true">
    <!-- we need a ROLE_ prefix in here -->
    <intercept-url pattern="/update/**" access="ROLE_OSTIUM-User"/>

    <!-- use own login page rather than the default one -->
    <form-login login-page="/login/login.jsp"/>
  </http>

  <!--
    Use with DummyDAO
  -->
  <!--<authentication-provider>
    <user-service>
      <user name="12345" password="12345" authorities="ROLE_USER"/>
      <user name="12346" password="12346" authorities="ROLE_USER"/>
    </user-service>
  </authentication-provider> -->

  <!--
    Use with JDBC
  -->
  <!--<authentication-provider>
    <jdbc-user-service
        data-source-ref="dataSource"
        users-by-username-query="SELECT ...;"
        authorities-by-username-query="SELECT ..."/>
  </authentication-provider> -->

  <authentication-provider user-service-ref="customUserService"/>
</beans:beans>

CustomUserDetailsService.java

package com.agimatec.ostium.security;

import com.agimatec.connecta.model.XFireUser;
import com.agimatec.connecta.xfire.WebXFireDAO;
import com.agimatec.nucleus.exceptions.CodedException;
import com.agimatec.nucleus.common.model.UserState;
import com.agimatec.usermanagement.service.XFireUserManagement;
import org.springframework.dao.DataAccessException;
import org.springframework.security.userdetails.UserDetails;
import org.springframework.security.userdetails.UserDetailsService;
import org.springframework.security.userdetails.UsernameNotFoundException;
import org.springframework.security.userdetails.User;
import org.springframework.security.GrantedAuthority;
import org.springframework.security.GrantedAuthorityImpl;

public class CustomUserDetailsService extends WebXFireDAO implements UserDetailsService {
    public CustomUserDetailsService() {
        super(XFireUserManagement.class);
    }

    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException, DataAccessException {
        try {
            // get the user from the XFire webservice
            XFireUser user = this.getService().getUserByIdentification(username);

            // extract all important parts
            String password = user.getPassword();
            String role = user.getRole();
            boolean enabled = user.isEnabled();

            // create a new Spring Security User
            return new User(username,password,enabled,true,true,true,new GrantedAuthority[] {new GrantedAuthorityImpl("ROLE_"+role)});
        } catch (CodedException e) {
            e.printStackTrace();
        }
        return null;
    }
}

Beispiel 1: Verwendung im AJAX-Layer

Um auf die Metadaten außerhalb von Java im JavaScript einer AJAX-GUI zugreifen zu können, wird aus den MetaBeans ein JSON-String erzeugt, den ein Servlet zurückgeben kann:

public void service( HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/javascript");
JSONGenerator jsonGenerator = new JSONGenerator();
PrintWriter writer = res.getWriter();
try {
String output = jsonGenerator.toJSON(manager.findAll().values());
writer.write(output);
} catch (Exception e) {
throw new ServletException("error creating JSON for metaBeans", e);
}
}


Dabei werden auch die Typinformationen von Java nach JSON übertragen, da diese ansonsten verloren gingen. Die Beans selbst überträgt das AJAX-Framework DWR, was nicht Gegenstand dieses Eintrages ist.

Beispiel 2: Verwendung im Webservice-Layer

Eine weitere Einsatzmöglichkeit stellt sich bei Validierung eingehender Objekte eines Webservice. Am Beispiel der Webservice Frameworks XFire oder CXF kann eine eigene Invoker-Implementierung konfiguriert werden, welche die eingehenden Beans validiert. Die zu validierenden Methoden und Parameter werden durch die Annotation @Validate gekennzeichnet.

Auszug aus einem Webservice-Interface:
@Validate
void save(@Validate Address address) throws ValidationException;

Entdeckte ConstraintViolations können der Exception mitgegeben werden.

Im Invoker wird das Validierungsframework aufgerufen (Beispiel für XFire):

public Object invoke(Method m, Object[] params, MessageContext context) throws XFireFault {
BeanValidator validator = new BeanValidator();
ValidationResults results = validator.validateCall( m, params);
if (results != null && !results.isEmpty()) {
throw new XFireFault(new ValidationException(results), XFireFault.RECEIVER);
}
return super.invoke( m, params, context);
}


Die zugehörige Konfiguration für XFire sieht dabei so aus:
<beans>
<bean id="TxInvoker" class="com.example.xfire.TransactionalInvoker"
scope="prototype"/>


<service xmlns="http://xfire.codehaus.org/config/1.0">
<name>ExampleService</name>
<serviceClass>com.example.service.ExampleService</serviceClass>
<implementationClass>com.example.service.ExampleServiceImpl</implementationClass>
<serviceFactory>jsr181</serviceFactory>
<invoker>#TxInvoker</invoker>
</service>
</beans>

Weitere Anwendungsmöglichkeiten sind die Visualisierung der Pflichtfelder und Validierungsfehler in Swing-GUIs oder einem Webformular.

Ausblick

Seit Oktober 2008 entsteht eine Referenzimplementierung, die sich an Hibernate-Validator orientiert. Von der veröffentlichten Draft-Spec des JSR-303
wurde dabei in den letzten Monaten mehrfach massiv abgewichen, um neue Features und Anregungen, die von der Java-Community eingegangen sind, einzubeziehen. Das agimatec-validation framework implementiert den jeweils aktuellen Stand der APIs möglichst zeitnah und vollständig. Wir gehen davon aus, dass sich bis zum offiziellen 1.0 Release des Standards noch mehrfach einiges ändern wird, da die Referenzimplementierung noch unvollständig ist.

Constraints in Annotations oder mit XML-Deskriptoren sind Metadaten, die den Domainklassen zusätzliche Semantik verleihen, die für diverse Verwendungszwecke mit der Constraint-Metadata-API ausgewertet werden kann.

Diese Anforderung bestand auch schon vor Zeiten der JSR-303 und hat die agimatec GmbH dazu veranlasst, das Framework „agimatec-validation“ im Frühjahr 2007 zu entwickeln. Das Framework ist seither als Basis zur Erzeugung dynamischer AJAX Oberflächen für Portlets und zur Validierung in Webservices produktiv im Einsatz.

Durch die konzeptionelle Nähe war es bei Erscheinen der JSR-303 möglich, das agimatec-validation Framework so zu erweitern, dass damit rasch die erste und bislang vollständigste Implementierung des Specification-Draft als OpenSource veröffentlicht wurde.

Zusätzliche Anforderungen waren dabei, dass

• eine möglichst automatische Generierung der Metadaten als XML-Dateien erfolgt,
• eine Klasse zur Laufzeit unterschiedliche Metadaten und Validierungsregeln besitzen kann (z.B. für rechteabhängige Validierung),
• die „höheren“ Schichten (hier: die GUI-Schicht) die Metadaten erweitern oder selektiv überschreiben können und
• die Metadaten den AJAX GUIs in Form von JSON (JavaScript Object Notation) zur Verfügung stehen sollen.

Generierung aus Datenbankinformationen

Die häufigsten Metainformationen betreffen Pflichtfelder und Feldlängen. Diese sind im Datenbankschema definiert oder durch Annotationen der Package javax.persistence
@Column(nullable, length, unique) oder
@JoinColumn(...)
an den Entity-Klassen definiert. Um aus dem Datenbankschema oder den Annotationen entsprechendes XML zu generieren bieten sich die als OpenSource verfügbaren agimatec-tools an (oder eine MDA-Lösung).

Das hier gezeigte XML folgt dem agimatec-validation Framework, da die JSR-303 bislang noch keine Aussage über XML-Tags getroffen hat:

<beanInfos>
<bean id=“Address“
impl=“test.jsr303.Address“>
<property name=“line1“
mandatory=“true“
maxLength=“30“/>
<property name=“line2“
maxLength=“30“/>
<property name=“zipCode“
mandatory=“true“
maxLength=“5“/>
...
</bean>
...
</beanInfos>


Features und Validators per XML

Häufige Eigenschaften sind direkt als Attribut deklarierbar, sonstige Informationen werden mit <feature>-Tags abgelegt:


<feature key="readonly">
<value class="boolean">true</value>
</feature>


Eigene Validator-Implementierungen werden über das <validator>-Tag konfiguriert:


<beanInfos>
<validator id="email"
java="my.own.EMailValidation"/>
<bean id=“Customer“>
<property name=“emailAddress“>
<validator refId="email"/>
</property>
</bean>
</beanInfos>


Nicht alle Metadaten sind zur Validierung relevant, sondern können für andere Zwecke z.B. zur Erzeugung einer Oberfläche genutzt werden. So können z.B. Feldreihenfolgen im Eingabeformular, Felder zur Darstellung in einer Tabelle oder die Properties zur Anzeige einer Beschreibung eines Objekts aus den Metadaten hervorgehen. Hier sind der Phantasie der GUI-Entwickler kaum Grenzen gesetzt.

Da die Metadaten aus diversen Quellen (Annotations, unterschiedlichen XML-Dateien und/oder den JDK-BeanInfos) zusammengestellt werden, können Zusatzinformationen beispielsweise in gesonderten XML-Dateien gehalten werden, während andere Informationen per Generierung zustande kommen.

Jede XML-Datei mit Metadaten muss registriert werden:

MetaBeanManager manager = new MetaBeanManager();
manager.addResourceLoader("beanInfos.xml");

Auf die Metadaten einer Domainklasse kann alternativ zur Metadata-API des JSR-303 direkt über den MetaBeanManager zugegriffen werden:

MetaBean metabean = manager.findForClass(Address.class);
// oder
metaBean = manager.findForId(„Address“);


Neben den seit Jahren bekannten proprietären Validierungsframeworks liegt seit März 2008 mit der JSR-303 ein Spezifikationsvorschlag für eine Java API für JavaBeans vor, der zukünftige Tools und Standards beeinflussen wird.

In den folgenden drei Einträgen stelle ich

a) Grundkonzepte der JSR-303
b) eine erste Implementierung des Standards
und
c) Beispiele für Integrationsmöglichkeiten und die Referenzimplementierung
vor.

Datenvalidierung ist eine allgemeine Aufgabe, die leider über die meisten Schichten einer Anwendung verteilt ist und dabei oftmals die Implementierung gleicher oder ähnlicher Regeln in jeder Schicht zur Folge hat. Dies führt zu doppeltem Code und Fehleranfälligkeit.

Für die Konsistenzprüfung umfangreicher Modelle von Businessentitäten müssen Validierungsregeln deklariert oder programmiert werden. Zu diesem Zweck gibt es seit Jahren bereits eine Vielzahl an proprietären Frameworks, einige Beispiele:

• Apache Common-Validator

• Struts-Validation für Webclients und JavaScript

• Hibernate-Validator (mit JBoss Seam Integration)

• WebWork mit XWork Validation Framework

Diese sind jedoch meist darauf ausgelegt, die Validierung in einer bestimmten Schicht der Anwendung abzusichern und sind sich allenfalls konzeptionell ähnlich. Einen Java-Standard für Deklaration und Prüfung von Validierungs-Constraints gab es bislang nicht.
Seit März 2008 liegt mit der „JSR-303: Bean Validation“ ein erster Vorschlag für einen allgemeinen Validierungsstandard im Javaumfeld vor, der zukünftig Einfluß auf Tools, Produkte und darauf aufbauende Standards haben soll. Ziel der Spezifikation ist es, als Erweiterung des Java-Beans Objektmodells in Java EE und SE eine einheitliche API für alle Schichten, sei es die Persistence Schicht, die Web Schicht und andere GUI-Schichten (z.B. Swing), zu bieten.

Grundkonzepte der Spezifikation

Als Metamodell zur Deklaration von Constraints schlägt der Draft der JSR-303 Annotationen für JavaBeans vor. Ferner wird in Aussicht gestellt, dass auch XML-Deployment-Descriptoren unterstützt werden sollen, was zum Zeitpunkt der Erstellung dieses Artikels aber noch nicht spezifiziert wurde. Alle Klassen der Spezifikation selbst werden sich im Package „javax.validation“ befinden.

Annotation der Domainklassen

Um für die Domainklasse „Address“ festzulegen, dass die Felder „line1“ und „zipCode“ Pflichtfelder sind und die Werte eine maximale Anzahl Zeichen nicht überschreiten dürfen, schreibt man:
public class Address {
@NotEmpty @Length(max = 30)
private String line1;
@Length(max = 30)
private String line2;
@NotEmpty @Length(max = 5)
private String zipCode;
...
}

Folgende Sprachkonstrukte dürfen hierzu mit Annotationen versehen werden:

• Instanzvariablen (field validation)
• Getter-Methoden (method validation)
• die Klasse selbst (bean-level constraints)
• Superklassen und
• Interfaces.

Es ist daher auch möglich, die Klasse „Customer“ durch Annotation ihres Interfaces „Person“ mit Constraints zu versehen:

public interface Person {
@NotEmpty
String getFirstName();
String getMiddleName();
@NotEmpty
String getLastName();
}


public class Customer implements Person {
private String firstName;
private String middleName;
private String lastName;
@Password(robustness = 5)
private String password;
...
}


Alle Constraints aus Oberklassen und Interfaces werden stets vererbt. Neben den Annotationen, welche die Implementierung der Spezifikation mitbringen wird, können beliebige eigene genutzt werden.

Eigene Constraints definieren
Zur Implementierung neuer Constraints müssen die entsprechende Annotation und ein ConstraintValidator erstellt werden.
Die Annotation wird im Domainmodell wie bereits dargestellt verwendet. Aufgerufen wird die Implementierung von einem Validator, welcher darüber entscheidet ob der Constraint erfüllt ist oder nicht.

Dazu folgt ein Beispiel für die Annotation „Pattern“:

@Documented
@Target({METHOD, FIELD})
@Retention(RUNTIME)
@ConstraintValidator(
PatternValidator.class)

public @interface Pattern {
String regex();
String message()
default "{beancheck.pattern}";
String[] groups() default {};
}

Die Implementierung „PatternValidator“ soll den Wert der annotierten Property gegen den angegebenen regulären Ausdruck aus „regex“ prüfen. Der ConstraintValidator PatternValidator muss das Interface „javax.validation.Constraint“ implementieren, das die Methode
boolean isValid(Object value, ConstraintContext constraintContext);
beinhaltet.

Mehrfache Zuweisung von Constraints gleichen Typs

Um mehrere gleiche Constraints mit unterschiedlichen Parametern für das gleiche Feld verwenden zu können, unterstützt die Spezifikation sogenannte „multi-valued constraints“. Eine Annotation darf hierbei die eigentlichen Constraint-Annotations als Array im Feld „value“ beinhalten:

@Documented
@Target({ElementType.METHOD, FIELD})
@Retention(RUNTIME)
public @interface Patterns {
Pattern[] value();
}


In der Verwendung liest sich dies dadurch folgendermaßen:

public class Engine {
@Patterns({
@Pattern(regex = "^[A-Z0-9-]+$"),
@Pattern(regex = "^....-....$")
})
protected String serialNumber;
...
}


Das Beispiel zeigt die Constraint-Definitionen zweier @Pattern für das Feld „serialNumber“ in einer Domainklasse namens „Engine“.

Für die eigentliche Validierung sieht die Spezifikation das Interface „Validator“ vor. Es definiert diverse validate*() Methoden für Objekte oder einzelne Properties, welche bei Verstoß gegen die festgelegten Validierungsregeln die Menge der entsprechenden ConstraintViolation Objekte zurückgeben:

Validator validator = ... ;
Set<ConstraintViolation<Address>>
errors = validator.validate(address);


for(ConstraintViolation each : errors) {
printInvalidContraint(
each.getPropertyPath(),
each.getInterpolatedMessage());
}

An welcher Stelle die Validierung in eine Anwendung integriert werden kann oder sollte ist nicht Bestandteil der Spezifikation.

Dieser Eintrag ist sowieso schon zu lang, aber alle Features im Detail zu zeigen, würde den Rahmen endgültig springen, daher hier einige weitere Features der JSR-303 stichpunktartig:

Validierung von Objektgraphen
Durch die Annotation „@Valid“ können auch referenzierte Objekte in die Validierung ihres Parent-Objects einbezogen werden. Auf diese Weise ist es möglich, mit einem Aufruf der Validierungs-API ganze Objektgraphen zu validieren.

Mehrsprachige Meldungen
Ein Constraint kann eine eigene Fehlermeldung im Annotation-Element „message“ festlegen. Die Spezifikation beschreibt die Möglichkeit, die Meldungen mehrsprachig in ein ResourceBundle auszulagern und in den Annotationen nur die sprachunabhängigen Schlüssel zu referenzieren.

Mit Class-Level Constraints können ganze Objekte anstatt einzelner Properties validiert werden. Als Anwendungsbeispiel kann man sich einen Validator vorstellen, der überprüft, ob die angegebene Stadt in einer Adresse zu Land und Postleitzahl passt.

Validierungsgruppen ermöglichen eine teilweise Validierung und werden von der Community noch diskutiert, wobei die Expert Group nach Möglichkeiten sucht, dies verständlich und gleichzeitig flexibel zu gestalten.
Eine Reihenfolge der Validierungen festzulegen ermöglicht die Annotation @GroupSequence.
Mit Hilfe der Gruppen und Reihenfolge ist es möglich, dass in einer Anwendungsschicht nur bestimmte Validierungen durchgeführt werden („Wizzard-Style“) um auch bereits unvollständig initialisierte Objekte prüfen zu können oder die Validierung so gestaltet wird, dass zeitaufwändige Verarbeitungen nachgelagert werden („Short-Circuit“).

Mit der Constraint-Metadata API wird eine Schnittstelle definiert, die Auskunft über die Constraints einer Klasse oder einzelner Properties gibt. Auch diese API steht noch nicht abschließend fest, dürfte aber für Toolhersteller von besonderem Interesse sein.

Wer mehr über die Spezifikation erfahren möchte, sei auf den Blog des Lead-Autors der JSR-303 verwiesen, der für alle Features auch Beispiele vorstellt.

We have written the application as a demo in the first place and now wanting to test it in the wild. Because we use Cairngorm the application is well structured and contains as view layer only minimal parts of logic. Yes, we could include unit tests, but integration tests are far more interesting (from my point of view). In a large code base it could happen, that because of refactoring some things are broken. No deal, if you have tests and a CI system. But in the Flex app there are just tiny parts which I could test in a normal unit test.

Okay, so it should be integration test. Sounds good and not too complicated. There should exist a lot of frameworks because a lot of people start to use BlazeDS and other stuff in Java environments. Just something to start the app, run some tests and get the result back in the CI system.

I started to search on google and was surprised. Most of the blog posts I have found on that topic are just two month old. And there are not so many posts about that topic. With the combination of those posts I figured out, how to solve that problem. What problem?

• Integration tests of our Flex app
• Integrated in Maven
• Should work together with Cairngorm (would be more complicated with some unit tests frameworks)
• Could be Selenium (to start the app and run tests)
• Should be integrated in our continuous integration server TeamCity
• Could be written in Java

First thanks to the blog post of Julia at Blackpepper. She opened my eyes how to work with Java and Flex in combination. It is the combination of the SeleniumFlexAPI, which integrates as Flex to Javascript bridge in your Flex application and FlashSelenium.

SeleniumFlexApi is in one part a Flex library which needs to be included in your app and on the other part an extension to the Selenium IDE. I like the Flex part, because it makes it easy to dive over Javascript into the details of your Flex app. What I don’t really like is the Javascript extension. Yes, it is not only a Selenium IDE part and you can include it into the start of the Selenium Server, but it is far away from Java and Maven.

FlashSelenium is a piece of code which let’s you talk from Java over Selenium with your Flex app. The Java part is very handy, but you need to code into Flex, which methods you could call over your bridge. So I need to write special code, which opens the bridge. The SeleniumFlexAPI is much better in this part.

I liked the solution of the blog post and started to implement it.

First the pom.xml where you need to include the SeleniumFlexAPI (the scope cost me some time):

<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>agimatec</groupId>
        <artifactId>assessor</artifactId>
        <version>1.0-SNAPSHOT</version>
        <relativePath>../pom.xml</relativePath>
    </parent>

  <modelVersion>4.0.0</modelVersion>
  <groupId>agimatec</groupId>
  <artifactId>assessor-flexapp</artifactId>
  <packaging>swf</packaging>
  <version>${agimatec-assessor-version}</version>
  <name>Assessor Flex Application</name>
  <url>http://www.agimatec.de</url>

  <dependencies>
    		 <!--Flex SDK dependencies-->
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>playerglobal</artifactId>
			<version>3.0.0.477</version>
			<type>swc</type>
		</dependency>
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>flex</artifactId>
			<version>3.0.0.477</version>
			<type>swc</type>
		</dependency>
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>framework</artifactId>
			<version>3.0.0.477</version>
			<type>swc</type>
		</dependency>
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>framework</artifactId>
			<version>3.0.0.477</version>
			<type>resource-bundle</type>
			<classifier>en_US</classifier>
		</dependency>
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>rpc</artifactId>
			<version>3.0.0.477</version>
			<type>swc</type>
		</dependency>
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>rpc</artifactId>
			<version>3.0.0.477</version>
			<type>resource-bundle</type>
			<classifier>en_US</classifier>
		</dependency>
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>utilities</artifactId>
			<version>3.0.0.477</version>
			<type>swc</type>
		</dependency>
    <dependency>
      <groupId>com.adobe.cairngorm</groupId>
      <artifactId>cairngorm-bin</artifactId>
      <version>2.2.1</version>
      <type>swc</type>
    </dependency>

      <dependency>
        <groupId>org.openqa.selenium</groupId>
        <artifactId>flex-api</artifactId>
        <version>0.22</version>
        <type>swc</type>
          <scope>internal</scope>
      </dependency>

		 <!--FlexUnit dependencies-->
		<dependency>
			<groupId>flexunit</groupId>
			<artifactId>flexunit</artifactId>
			<version>0.85</version>
			<type>swc</type>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>flexunit.junit</groupId>
			<artifactId>flexunit-optional</artifactId>
			<version>0.85</version>
			<type>swc</type>
			<scope>test</scope>
		</dependency>
  </dependencies>

  <build>
    <sourceDirectory>src/main/flex</sourceDirectory>
    <plugins>
      <plugin>
        <groupId>info.rvin.mojo</groupId>
        <artifactId>flex-compiler-mojo</artifactId>
        <extensions>true</extensions>
        <configuration>
          <includeSources>
            <param>${project.build.sourceDirectory}</param>
          </includeSources>
          <locales>
            <param>en_US</param>
            <param>de_DE</param>
          </locales>
          <debug>true</debug>
        </configuration>
      </plugin>
      <plugin>
        <groupId>info.rvin.mojo</groupId>
        <artifactId>asdoc</artifactId>
      </plugin>
    </plugins>
  </build>
</project>

To get the Flex application compile with Maven you need to download the SeleniumFlexAPI and include the swc-file into your Maven repository, because it is (not yet) available on public repositories.

After compiling you can start the Selenium IDE and load the extension or go directly to FireBug and try to call the methods. Be aware, that the args-parameter is normally optional, but needs to be filled for the Javascript-Flex bridge (also cost me some time).

To call a method of your running application in Firefox fire up in FireBug’s console:

window.document['AppName'].getFlexExists('NameOfAnElement','');

To test your application you need to know, what the name of your application is (can be found in the HTML calling the Flash file) and you need to give ids to your elements, because there is just an id locator at the moment.

If you are at this point we can now switch to the Java part with Selenium. Selenium is just Javascript when you are in the browser. So all you do is to call the Javascript function which you called before over Firebug. FlashSelenium is a good wrapper for that call which means that you don’t have to write normal strings into your Selenium commands. I like a little bit more comfort and wanted to wrap the SeleniumFlexAPI a little bit closer. Also there are some methods in the FlashSelenium you don’t need with this solution. So I started to implement my own little wrapper. Maybe it is also interesting for the SeleniumFlexAPI (if completed with all methods).

Here is the beginning of the code:

package com.agimatec.assessor.selenium;

import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.Selenium;

public class FlexSelenium {
    Selenium selenium;
    String flexApp;

    public FlexSelenium(String ip, int port, String browser, String url, String flexApp) {
        selenium = new DefaultSelenium(ip, port, browser, url);
        this.flexApp = flexApp;
    }

    public void start() {
        selenium.start();
    }

    public void open(String url) {
        selenium.open(url);
    }

    public void stop() {
        selenium.stop();
    }

    public String doFlexClick(String id) {
        return callFlexBridge("doFlexClick",id);
    }

    public boolean getFlexExists(String id) {
        return callFlexBridge("getFlexExists",id).equals("true");
    }

    private String callFlexBridge(String method, String id) {
        return callFlexBridge(method, id, null);
    }

    private String callFlexBridge(String method, String id, String args) {
        if(args == null || args.trim().equals("")) {
            args = "''";
        }
        return selenium.getEval("window.document['"+flexApp+"']."+method+"('"+id+"',"+args+");");
    }
}

And now the test case is the only thing which is missing. I used TestNG because it can be easier configured in a Selenium environment (when it started to become more complicated with several browsers, plattforms, test suites, test groups …):

package com.agimatec.assessor.selenium;

import org.testng.annotations.Test;

public class AssessorTest {
    private final static String URL = "http://192.168.1.175:8080/assessor-webapp";
    FlexSelenium selenium;

    @Test
    public void setUp() throws InterruptedException {
        selenium = new FlexSelenium("192.168.1.254", 4444, "*firefox", URL, "Terminal");
        selenium.start();
        selenium.open(URL);
        while(!selenium.getFlexExists("videoPlayer")) {
            Thread.sleep(1000);
        }

        selenium.doFlexClick("videoPlayer");
        Thread.sleep(300);
        selenium.doFlexClick("enterUserModeButton");
        selenium.stop();
    }
}

You can find some posts around Selenium in this blog, but I want to get in more detail. Also there are some improvements to the solutions which could be really interesting if you start with Selenium or get an idea, how others deal with larger Selenium test suites. I will try to publish a new part every week, because there is so much to say, which wouldn’t fit into one single post.

Goals:

• Continuous integration of web application tests
• Tests in different browsers
• TestNG Setup
• Integration in Maven2
• Faster Selenium tests

Tests:

• Running use cases of the web application
• Running Javascript Unit Tests in different browsers
• Take screenshots of the application

I’m a web developer and no full-time tester, that’s why you should see the posts as support in an agile environment. There are different solutions and methods to test a web application, but I feel very comfortable with coding my tests and provide solutions which helps in the day-to-day work.

Until I will continue with the series, you can have a look at the previous posts:

• Testing of Web 2.0 interfaces (in german, but you will understand the code part)
• Robust portlet testing
• Selenium CI tests with TeamCity
• Selenium testing of massive Ajax Apps

You might already know various ways to process XML with java objects or to transform XML into different formats. XML transformation with XSLT can be quite difficult to implement because its concept differs from usual programming approaches.

I like the framework XStream to parse and generate XML because of its simple but flexible API. You can configure the XML with annotations on plain java classes, no XML schema or DTD is required. XStream’s documentation shows you in two minutes how to use it.

We are using XStream to process XML-messages asynchronously between clients and a server, where some clients might use an older XML dialect than others. This leads to the requirement that the server must support various versions of XML messages for both receiving and sending with its clients. We use XStream not only to process the messages but for transformation as well.

In short terms, the concept:

current version: classes and annotations

former versions: classes, different configuration and converters

XML is marshaled into POJOs and back. The POJOs and their annotations fit to the current version of the XML dialect of the server.

Example for a class “Box”:

@XStreamAlias("Box")
public class Box {
  Long number;
  boolean defect;
  boolean soiled;
  // getters and setters...
}

The corresponding XML is:

<Box>
  <number>1</number>
  <defect>false</defect>
  <soiled>false</soiled>
</Box>

Various aspects on the XML can change during evolution of the schema. I adjust the annotations and classes, but how to provide backward compatibility?

I use the same classes with a different XStream configuration. For each version I need to support, I implement the interface XStreamConfigurator. This is the interface I created to initialize an instance of XStream.

public interface XStreamConfigurator {
    void configure(XStream xstream);
}

The current version, based on annotations just lists the classes that participate in XML marshaling:

xstream.processAnnotations(Box.class); // ... for each class

To provide XML marshaling/unmarshaling for other versions with the same class, I implement XStreamConfigurator differently:

Example 1: changed tags

e.g. “Pocket” instead of “Box”, “id” instead of “number”

xstream.alias("Pocket", Box.class);
xstream.aliasField("id", Box.class, "number");

This overrules the annotations.

Example 2: attribute instead of element

e.g. “defect” as attribute instead of element

xstream.useAttributeFor("defect", Box.class);

Example 3: new fields

When the current version has additional fields, you can tell XStream to omit them.

xstream.omitField(Box.class, "soiled");

Example 4: custom converter

Some classes could change so heavily, that you need to implement a converter to marshal and unmarshal XML from old version into your classes. The example supports the additional xml element “active”, that does not appear in class Box.

xstream.registerConverter(new BoxConverter_v1());
...
public class BoxConverter_v1 implements Converter {
 public void marshal(Object source, HierarchicalStreamWriter writer,
                     MarshallingContext context) {
        Box box = (Box) source;
        writeNode(writer, "id", box.getNumber(), context);

        writeNode(writer, "defect", box.isDefect(), context);
        writeNode(writer, "active", true, context); // additional xml element "active"
    }

 public Object unmarshal(HierarchicalStreamReader reader, UnmarshallingContext context) {
        Box box = new Box();
        while (reader.hasMoreChildren()) {
            reader.moveDown();
            String nn = reader.getNodeName();
            if ("id".equals(nn)) {
                box.setNumber((Long) context.convertAnother(box, Long.class));
            } else if ("defect".equals(nn)) {
                box.setDefect(Boolean.parseBoolean(reader.getValue()));
            } else if ("active".equals(nn)) {
                // ignore, always "true"
            }
            reader.moveUp();
        }
        return box;
    }

    public boolean canConvert(Class type) {
        return type.equals(Box.class);
    }

    protected void writeNode(HierarchicalStreamWriter writer, String nodeName, Object value,
                             MarshallingContext context) {
        if (value != null) {
            writer.startNode(nodeName);
            context.convertAnother(value);
            writer.endNode();
        }
    }
}

Example 5: changed nested parts and new classes

Finally I assume that the current version wraps the “Box” element under an “Action” element, so that class “Action” contains the “Box”.

@XStreamAlias("Action")
public class Action {
  private Box box;
  // getter and setters...
}

XML looks like:

<Action>
  <box>
    <number>1</number>
    <defect>false</defect>
    <soiled>false</soiled>
  </box>
</Action>

To configure the instance of XStream that supports the former version, I write:

  xstream.registerConverter(new BoxConverter_v1());
  xstream.registerConverter(new ActionConverter_v1());
// Whenever XStream encounters an instance of this type,
// it will use the default implementation instead.
  xstream.addDefaultImplementation(Action.class,  Box.class);

The ActionConverter is just a delegate to BoxConverter:

public class ActionConverter_v1 extends BoxConverter_v1 {

    public void marshal(Object source, HierarchicalStreamWriter writer,
                        MarshallingContext context) {
        Box box = ((Action) source).getBox();
        super.marshal(box, writer, context);
    }

    public boolean canConvert(Class type) {
        return type.equals(Action.class);
    }
}

So when you generate XML for an instance of Action, you call

xstream.toXML(action);

but you still get

<Pocket>
  <id>1</id>
  ...
  <active>true</active>
</Pocket>

These examples show some possibilities for transformation with XStream. To transform old XML into current XML you unmarshal with one XStream instance and marshal with another. XStream is not restricted to generate XML, you can also generate JSON or build your own formats.

Some of this plugins like clean, compile, install and others you are using everday. Maybe without to know that these are plugins.

Most of the plugins are highly configurable which helps you in the most situations. Most of the plugins are well documented on their own websites.

In this post I will present our 10 most valuable Maven plugins.

1.  Maven AntRun Plugin

The Maven AntRun Plugin is the plugin we use whenever we want to do little tasks. Maven is great in solving dependencies, but Ant is very helpful in a lot of situations. Maybe you want to copy files or integrate existing Ant tasks. Yes, you can sit down and write your own Maven plugin in this situations, but then you have to deploy the plugin to all team members and have a lot of overhead in implementing your own plugin. In most situations it is easier to write a few lines of ant configuration in your pom.xml

2. Maven Surefire Plugin

The Maven Surefire Plugin is normally used, when you start the command mvn test or when you are executing a goal which includes the test goal (read more about this in Maven2 Build Lifecycle). If you are using the standard directory layout of Maven your tests can be found at src/test/java. If there are tests in this directory the Maven Surefire Plugin will automatically run these tests and generate reports including the results in the directory target/surefire-reports. Opposite to the documentation on the plugin page, the Maven Surefire Plugin will run JUnit 3/4 tests as well as TestNG tests.

3. Maven Site Plugin

The Maven Site Plugin is used more frequently but maybe not known to everybody. With the Maven Site Plugin you can generate a complete website for your project. All you need to do is to call mvn site and wait for the site to appear in the target directory. If you are developing a public available project, it is maybe all you need to generate your own website. A lot of information is taken from your configuration but you can easily include your own pages and content. We use it to include reports about our code: test results, test coverage, resolved dependencies and many more. For more information about the available reports have a look at the report plugin section on this page.

4. Maven Archetype Plugin

With the Maven Archetype Plugin you can easily generate a scaffolding of a project. You need a Struts2 application? Try out the following code:

mvn archetype:create   -DgroupId=tutorial \
                       -DartifactId=tutorial \
                       -DarchetypeGroupId=org.apache.struts \
                       -DarchetypeArtifactId=struts2-archetype-starter \
                       -DarchetypeVersion=2.0.5-SNAPSHOT \
                       -DremoteRepositories=http://people.apache.org/repo/m2-snapshot-repository

There are archetypes for a lot of project types and you can also build your own project template. We use it to generate a stub for a portlet module with our full technology stack.

5. Maven IDEA Plugin

It can be a pain to configure the IDE with all the required libraries and settings for a project. With the Maven IDEA Plugin or the Maven Eclipse Plugin you can generate ready to start project settings files. It was important until Jetbrains had improved the Maven Support in version 7 of IntelliJ. Maybe it is still helpful for you.

6. Maven Jetty Plugin

When developing Java web applications you often find yourself configuring Tomcat, deploying WAR-files and restarting your Tomcat. With the Maven Jetty Plugin all you need to do is to call mvn jetty:run. It was never so easy to start and develop your Java web projects, because this server is running on the actual files. No copying, no deploying while your are developing. I really like it, because this one is speeding up your daily work.

7. Maven Cargo Plugin

The Maven Cargo Plugin is great for getting a container with your artifacts running. You need a JBoss? This plugin can download and start a JBoss. You need to deploy your artifacts and check until the server is started, you can use this plugin. The configuration can be a little tricky and especially when you are using features like container managed security.

8. Maven Dependency Plugin

Most problems with Maven occur in resolving the right dependencies. Often you don’t know, where the version of a library comes from or why the library is included in your artifact. With the Maven Dependency Plugin you can get all the infos you need:

• mvn dependency:tree will give you a tree view of the resolved dependencies
• mvn dependency:analyze-dep-mgt will find mismatches in your dependencyManagement section

9. Maven Javadoc Plugin

The Maven javadoc Plugin is a reporting plugin and will generate the Javadoc of your project and will include it into the site. Your Maven site can be a central point for your team members to get information about your project. The Javadoc could be one part and it is often very helpful to deploy the Maven site on a central server with your CI builds. If you are developing parts in Javascript there is also a JsDoc plugin available.

10. Maven WAR Plugin

The Maven WAR Plugin is a of the type packaging and will generate a ready to run WAR file.  If you are using the standard directory layout all you need to do is to declare the type of your project as WAR and call mvn install. You can copy this WAR file into your Java web container (eventually with the Maven AntRun Plugin) and get your application running. Very helpful is the filtering feature of Maven which also works with the WAR plugin. It is very important in this case, because you can’t change or patch anything, after the WAR file is packaged.

Our plugins

Because we are facing situations where no plugin for a problem is available, we have written some plugin and released it as open source.

Maven Sizewatch Plugin: Include the plugin in the maven “verify” or “install” phase to check, that an artifact does not exceed a predefined size. This plugin can be useful to check the size of .war archives, that might contain more libs than expected when some transient dependencies have changed.

Maven Wait Plugin: We’re doing automated integration tests via Xen containers, so we didn’t need a full blown cargo installation – instead we’ve a full blown JBoss installation with database fresh and ready for tests. The wait plugin just makes sure that tests are started as soon as the server is up and running.