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.

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.

You can download it here.

Nabaztag

A Nabaztag is a WiFi enabled electronic device with a text to speech engine, rotating ears and colorful leds. When connected to your WiFi it can read mails, RSS feeds, weather forecast or can be accessed with a API. You are not directly connected to the bunny, all messages are sended and managed by the Nabaztag server.

TeamCity

We manage our continuous integration with TeamCity. It is a product of JetBrains, the guys with the great IntelliJ Idea IDE. Before we started using TeamCity we had CruiseControl running. The configuration was very complicated and the interface wasn’t an eye catcher. With TeamCity we can configure all our Maven2 builds in a nice web interface with a lot of usefull settings. There is also an IDE plugin with the possibility to have personal remote builds. The only problem was the silence of our build bunny, which was running with CruiseControl before. With the Nabaztag plugin we want to close this gap for the TeamCity and Nabaztag community.

Screenshots

Links

BuildBunny at Google Code: http://code.google.com/p/buildbunny/

Nabaztag: http://www.nabaztag.com

TeamCity: http://www.jetbrains/teamcity

Unsere agimatec-tools sind nun als OpenSource Projekt auf google.code veröffentlicht. Wir setzen diese Tools und Frameworks bereits seit über einem Jahr produktiv in unseren Produkten ein.

Drei Tools verbergen sich bisher hinter “agimatec-tools”:

1. Ein Database-Migration Tool zum setup/alter/check von Datenbanken. Projekte, die eine oder mehrere Datenbanken (oder Datenbanken unterschiedlicher Hersteller) pflegen und weiterentwicklen, können mit diesem Werkzeug das Deployment/Upgrade ihrer Datenbanken durchführen und prüfen, ob das Schema vollständig und korrekt ist. (Beispielprojekt anbei)

Das Tool erlaubt auch die Verarbeitung (Parsen, Transformation, Code-Generierung) von SQL-Scripten.

2. Ein Framework zum Datenimport, das es vor allem mit einem Groovy-Script einfach macht, CSV-Dateien, XML-Dateien und andere Textformate zu importieren. (Wir setzen es z.B. gemeinsam mit dem Datenbank-Migration-Tool ein um einen initialen Datenimport aus vom Kunden gelieferten Dateien durchzuführen.)

3. Das Tool “annomark” (annnogen+freemarker) zur Generierung von Code durch Annotationen, wie bereits in einem früheren Beitrag angekündigt: “TransferObjects generieren“. Mit Annomark lassen sich flexible Verarbeitungen, nicht nur die Generierung von TransferObjekten, realisieren. (Ein Beispielprojekt demonstriert weitere Möglichkeiten.)

Die Veröffentlichung beinhaltet nicht nur Source und Binaries, sondern bietet auch Beispielprojekte und -templates, die für eigene Maven-Projekte verwendet werden können und umfassend die Verwendung der APIs demonstrieren. Auf google.code sind die Frameworks jeweils ausführlich im Wiki auf Englisch dokumentiert.

Jetzt sind wir gespannt auf Rückmeldungen und Anregungen und freuen uns, wenn diese Tools dem einen oder anderen weiterhelfen können!

Plugin 1: verifysize
Das Problem: Manchmal bemerkt man recht spät, dass die Größe von .ear oder .war Archiven mal wieder unerwartet angewachsen ist, z.B. weil sich indirekte Abhängigkeiten im Projekt geändert haben. Das “verifysize” Plugin prüft die Größe des Artefakts. Überschreitet (oder unterschreitet) sie einen angegeben Wert, so schlägt der Build (wahlweise) fehl.
Durch diesen zeitnahen Hinweis läßt sich die Ursache meist schnell finden.

Plugin 2: wait
Das Problem: Eines unserer Maven-Projekte soll Integration-Tests gegen eine Serverinstallation ausführen. Der Server wird deployed und nach einiger Zeit von einem cron-Job automatisch gestartet. Das Maven-Projekt muß aber so lange warten, bis der Serverstart abgeschlossen ist, bevor mit der Ausführung der Integration-Tests begonnen wird.
Mit dem “wait” Plugin kann der Buildprozess auf die Verfügbarkeit einer (oder mehrerer) URLs warten, z.B. darauf, dass die zu testende Webanwendung oder der benötigte Webservice verfügbar ist.
(Die Verwendung des cargo-Plugins war mir für dieses Problem zu komplex.)

Download und Dokumentation:
http://code.google.com/p/agimatec-maven-plugins/