Maven ist ein build Tool und Framework für java, welches es sich zum Ziel gemacht hat dem Anwender möglichst viele Schritte abzunehmen. In der allmächtigen pom.xml werden alle relevanten Optionen konfiguriert und ansonsten mit Konventionen in Form von Verzeichnissturktur und Dateinamen gearbeitet.

Das Framework erhält durch seine Pluginfähigkeit eine gute Flexiblität und ermöglicht viele Aufgaben durch ein wenig Konfiguration zu lösen.

Ich will hier eine maven Version meines vorherigen Apache ant Beispiels zeigen, die zum gleichen Ergebnis führt. Zudem gibt es einen kleinen Unit-Test, da das Framework deren Einbindung direkt mitbringt.

(Die resource files und merge Datei liegen bewusst in einem Verzeichnis um herauszufinden wie man die Filter verwendet.)

Code

Verzeichnisstruktur

Die Grundstruktur von Maven ist dabei standardmäßig wie folgt:

pom.xml
src/main
src/resources
src/test
src/test/resources

Im Beispiel:

./pom.xml

./src
./src/main
./src/main/java
./src/main/java/de
./src/main/java/de/benjaminpeter
./src/main/java/de/benjaminpeter/print
./src/main/java/de/benjaminpeter/print/LoadFile.java
./src/main/java/de/benjaminpeter/print/Print.java

./src/main/resources
./src/main/resources/resources
./src/main/resources/resources/inputA
./src/main/resources/resources/inputB
./src/main/resources/resources/merge
./src/main/resources/resources/file

./src/test
./src/test/java
./src/test/java/de
./src/test/java/de/benjaminpeter
./src/test/java/de/benjaminpeter/print
./src/test/java/de/benjaminpeter/print/LoadFileTest.java

./src/test/resources
./src/test/resources/resources
./src/test/resources/resources/file

Java src (analog zum ant Beispiel)

import java.io.*;
import java.lang.*;

public class LoadFile {
  public String load() throws FileNotFoundException, UnsupportedEncodingException, IOException {
    // File file = new File("resources/file");
    // FileInputStream fis = new FileInputStream(file);
    // Datei ist nun im jar, also muss sie anders geladen werden
    ClassLoader cl  = this.getClass().getClassLoader();
    InputStream fis = cl.getResourceAsStream("resources/file");
    // import groovy ... file.text ... :-/
    BufferedReader in = new BufferedReader(new InputStreamReader(fis));
    String str = "";
    String ret = "";
    while ((str = in.readLine()) != null) ret += str + '\n';
    return ret.substring(0, ret.length() - 1);
  }
}

import java.lang.*;

public class Print {
  public static void main(String[] args) {
    System.out.println("Hello.");
    try {
      System.out.println("Content:\n"+
        new LoadFile().load());
    }
    catch (Exception e) {
      System.err.println("Error: "+ e.getMessage());
    }
  }
}

Ressourcen

File: resources/file

A: Build @buildNumber@
If the writeList method doesn't
catch the checked exceptions
that can occur within it, the
writeList method must specify
that it can throw these
exceptions. Let's modify the
B:
original writeList method to
specify the exceptions it can
throw instead of catching
them. To remind you, here's
the original version of the
writeList method that won't
compile.
File: resources/inputA

A: Build @buildNumber@
If the writeList method doesn't
catch the checked exceptions
that can occur within it, the
writeList method must specify
that it can throw these
exceptions. Let's modify the
File: resources/inputB

B:
original writeList method to
specify the exceptions it can
throw instead of catching
them. To remind you, here's
the original version of the
writeList method that won't
compile.
File: resources/merge

#!/bin/sh
cat $1 $2 > $3

Hierbei musste ich @date@ zu @buildNumber@ ändern, da es ohne größeren Aufwand nicht möglich properties in anderen properties zu verwenden. (Falls es jemand besser weiß immer her damit, finde das durchaus wichtig)

pom.xml

<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">
  <!-- Basisinformationen zum Projekt -->
  <modelVersion>4.0.0</modelVersion>
  <groupId>de.benjaminpeter.print</groupId>
  <artifactId>Print</artifactId>
  <packaging>jar</packaging>
  <!-- Version des Projekts in maven, der Name des
       Jars kann noch einmal extra definiert werden! -->
  <version>0.0.1</version>
  <name>Print</name>
  <url>http://maven.apache.org</url>
  <!-- Default dependency fuer Unit-Tests, bibliothek
     wird automatisch herunter geladen -->
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <!-- scope:
           Gibt an, dass diese Abhaengigkeit nur
           zum Testen benötigt wird. Das heißt sie wird
           auch nur beim Ausführen der Tests
           heruntergeladen und ist im
           finalen jar/war nicht enthalten. -->
      <scope>test</scope>
    </dependency>
  </dependencies>
  <build>
    <!-- Binde die resource "resources/file" ein, dies
         wird dynamisch erzeugt wie wir später sehen. -->
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <includes>
          <include>resources/file</include>
        </includes>
         <!-- Zudem soll hier das
          Filtering aktiviert werden,
         das heißt wir lassen maven einen
         Platzhalter @buildNumber@ in der
         Datei ersetzen. -->
        <filtering>true</filtering>
      </resource>
    </resources>
    <plugins>
      <!--
        Binde ein Plugin ein um die Build Nummer
        variabler erstellen zu können. Hiermit machen
        wir die Variable buildNumber vom aktuellen
        Datum abhängig.
        Auch das Plugin wird von maven bei Bedarf
        dynamisch herunter geladen. -->
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>buildnumber-maven-plugin</artifactId>
        <configuration>
          <format>{0,date,yyyyMMdd}</format>
          <items>
            <item>timestamp</item>
          </items>
        </configuration>
        <!-- Diese Block besagt, dass das Plugin in
             der validierungsphase (ganz am Anfang)
             ausgeführt werden soll. create ist dabei
             eine von mehreren Funktionen des Plugins
             die dabei aufgerufen werden soll. -->
        <executions>
          <execution>
            <phase>validate</phase>
            <goals>
              <goal>create</goal>
            </goals>
          </execution>
        </executions>
       </plugin>
       <!-- Mit dem jar Plugin können wir
          die Erzeugung des jar Files etwas
          anpassen. So setzen wir hier die
          MainClass fest um ein einfach
         ausführbares jar zu bekommen. -->
       <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-jar-plugin</artifactId>
         <configuration>
           <archive>
            <manifest>
              <mainClass>Print</mainClass>
              <packageName></packageName>
            </manifest>
            <manifestEntries>
              <mode>development</mode>
              <url>${pom.url}</url>
            </manifestEntries>
          </archive>
        </configuration>
      </plugin>
      <!-- exec Plugin, dies ermöglicht es alle
           Schweinereien zu machen die man
           sonst nicht hinbekommt.
           Wird hier auch zur Verfizierungsphase
           ausgeführt und ruft den Befehl "merge"
           aus dem resources Verzeichnis auf
          um die Datei "file" zu erzeugen.

           An dieser Stelle könnte man sicher auch
           ein Ant Plugin einbinden um komplexere
           Abläufe zu realisieren und Abhängigkeiten
           sowie bereits angelegte Dateien erkennen
           zu können. -->
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>exec-maven-plugin</artifactId>
        <version>1.1</version>
        <executions>
          <execution>
            <phase>verify</phase>
            <goals>
              <goal>exec</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <executable>./merge</executable>
          <workingDirectory>${basedir}/src/main/resources/resources</workingDirectory>
          <arguments>
            <argument>inputA</argument>
            <argument>inputB</argument>
            <argument>file</argument>
          </arguments>
        </configuration>
      </plugin>
    </plugins>
    <!-- Setze den Namen der jar Datei so, dass
         auch unsere im Plugin
         erzeugte buildNumber eingesetzt wird. -->
    <finalName>${project.artifactId}-${buildNumber}</finalName>
  </build>
  <properties>
    <!-- Funktioniert leider nicht :-/ -->
    <date>${buildNumber}</date>
  </properties>
</project>

Ausführung

Build

$ mvn install
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Print
[INFO]    task-segment: [install]
[INFO] ------------------------------------------------------------------------
Downloading: http://repo1.maven.org/maven2/net/java/dev/jna/jna/3.0.5/jna-3.0.5.pom
Downloading: http://repo1.maven.org/maven2/net/java/dev/jna/jna/3.0.5/jna-3.0.5.pom
[INFO] [buildnumber:create {execution: default}]
[INFO] Storing buildNumber: 20091030 at timestamp: 1256918122611
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 2 source files to /home/dedeibel/proggn/java/test/mvn-example/Print/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to /home/dedeibel/proggn/java/test/mvn-example/Print/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory: /home/dedeibel/proggn/java/test/mvn-example/Print/target/surefire-reports

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

Results :

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

[INFO] [jar:jar]
[INFO] Building jar: /home/dedeibel/proggn/java/test/mvn-example/Print/target/Print-20091030.jar
[INFO] [exec:exec {execution: default}]
[INFO] [install:install]
[INFO] Installing /home/dedeibel/proggn/java/test/mvn-example/Print/target/Print-20091030.jar to /home/dedeibel/.m2/repository/de/benjaminpeter/print/Print/0.0.1/Print-0.0.1.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7 seconds
[INFO] Finished at: Fri Oct 30 16:55:26 CET 2009
[INFO] Final Memory: 31M/290M
[INFO] ------------------------------------------------------------------------

Programm

$ java -jar target/Print-20091030.jar
Hello.
Content:
A: Build 20091030
If the writeList method doesn't
catch the checked exceptions
that can occur within it, the
writeList method must specify
that it can throw these
exceptions. Let's modify the
B:
original writeList method to
specify the exceptions it can
throw instead of catching
them. To remind you, here's
the original version of the
writeList method that won't
compile.

Fazit

Den direkten Vergleich zwischen ant und maven fand ich sehr interessant. Im kleinen Beispiel kann man die Stärken von maven jedoch nur erahnen. So hätte es bei ant wieder einer extra Einbindung der Unit-Tests bedurft, die aber im Grunde für jedes Projekt gleich ist wenn man sich an die Konventionen hält. Weiterhin musste kein Finger krum gemacht werden um eine aktuelle Version der junit Abhängigkeit zu bekommen; ein großer Vorteil bei einem Umzug auf ein anderes System, sofort werden die benötigten Abhängigkeiten ohne Aufwand nachgezogen.

Der Teufel steckt im Detail, während das Anpassen des Dateinamens und Ausführen des merge Skripts bei ant ein Kinderspiel sind, da man hier direkt auf die Abhängigkeiten und jar Erstellung Einfluss hat, scheint der Weg bei Maven für alles ein Plugin installieren zu müssen doch etwas umständlich. Letztendlich ist es aber eine Gute Sache, da es Plugins für die Unterschiedlichsten Aufgaben gibt und diese einem wie maven selbst möglichst viel Arbeit abnehmen. Allgemein sollte man sich vielleicht weniger mit Details aufhalten und gerade bei Verwendung von Frameworks Kompromisse eingehen und sich an die Gegebenheiten gewöhnen. Bei großen Projekten ist es auch so schwer genug die Übersicht zu behalten.

Quellen

Apache maven
Maven getting started

Die Vernachlässigung von tollen Namespaces für meine Klassen sie mir verziehen.

The following is the sample snippet used to perform remote deployment in tomcat using cargo plugin

<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<configuration>
<container>
<containerId>tomcat5x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.tomcat.manager.url>http://localhost:8080/manager/html</cargo.tomcat.manager.url>
<cargo.remote.username>admin</cargo.remote.username>
<cargo.remote.password>admin</cargo.remote.password>
</properties>
<deployables>
<deployable>
<groupId>groupId</groupId>
<artifactId>artifactId</artifactId>
<type>war</type>
</deployable>
</deployables>
</configuration>
</configuration>
</plugin>
</plugins>
</build>

–> check your %TOMAT_HOME%/conf/tomcat-users.xml for tomcat manager user name and password

Today I have reviewed a proof of concept I have done in order to decide which Web Services framework matches the requirements of a bioinformatics project. Because of forgetting to store a file in the versioning system, I had to review the whole tutorial and to look for the file within the Spring tutorial. What is interesting, until now nobody published the full content of the Spring-WS tutorial.

So, here is my pom.xml. I am using Apache Maven2 in order to strictly enforce the versions of the JAR files. Nobody is constrained to use Maven, but without it, it would be very difficult to sort out the transient dependencies.

<?xml version="1.0" encoding="UTF-8"?>
<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">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.razvan.hr</groupId>
 <artifactId>holidayService</artifactId>
 <packaging>war</packaging>
 <version>1.0-SNAPSHOT</version>
 <name>holidayService Spring-WS Application</name>
 <url>http://www.springframework.org/spring-ws</url>
 <build>
 <finalName>holidayService</finalName>
 <plugins>
 <plugin>
 <groupId>org.mortbay.jetty</groupId>
 <version>6.1.9</version>
 <artifactId>maven-jetty-plugin</artifactId>
 </plugin>
 </plugins>
 </build>
 <dependencies>
 <dependency>
 <groupId>org.springframework.ws</groupId>
 <artifactId>spring-ws-core</artifactId>
 <version>1.5.8</version>
 </dependency>
 <dependency>
 <groupId>jdom</groupId>
 <artifactId>jdom</artifactId>
 <version>1.0</version>
 </dependency>
 <dependency> <!-- required by AbstractJDomPayloadEndpoint -->
 <groupId>jaxen</groupId>
 <artifactId>jaxen</artifactId>
 <version>1.1</version>
 <scope>runtime</scope>
 </dependency>
 <dependency>
 <groupId>javax.xml.soap</groupId>
 <artifactId>saaj-api</artifactId>
 <version>1.3</version>
 <scope>runtime</scope>
 </dependency>
 <dependency>
 <groupId>com.sun.xml.messaging.saaj</groupId>
 <artifactId>saaj-impl</artifactId>
 <version>1.3</version>
 <scope>runtime</scope>
 </dependency>
 <dependency>
 <groupId>xalan</groupId>
 <artifactId>xalan</artifactId>
 <version>2.7.1</version>
 </dependency>
 </dependencies>
</project>

I am using the jetty plugin in order to be able to run the application right from the command line; xalan dependency is required in order to avoid the exception “java.lang.IllegalStateException: Could not find SAAJ on the classpath” thrown by Spring-WS, corrected in a newer version of xalan.

Also according to the tutorial, the file spring-ws-servlet.xml, a regular Spring context file, describes the external interface of the Web Service and the associated Java classes. This file has to be placed in the src/main/webapp/WEB-INF directory.

<?xml version="1.0" encoding="UTF-8"?>
<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">

 <bean id="holidayEndpoint" class="com.razvan.hr.ws.HolidayEndpoint">
 </bean>

 <bean class="org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping">
 <property name="mappings">
 <props>
 <prop key="{http://mycompany.com/hr/schemas}HolidayRequest">holidayEndpoint</prop>
 </props>
 </property>
 <property name="interceptors">
 <bean class="org.springframework.ws.server.endpoint.interceptor.PayloadLoggingInterceptor" />
 </property>
 </bean>

 <bean id="holiday" class="org.springframework.ws.wsdl.wsdl11.DynamicWsdl11Definition">
 <property name="builder">
 <bean class="org.springframework.ws.wsdl.wsdl11.builder.XsdBasedSoap11Wsdl4jDefinitionBuilder">
 <property name="schema" value="/WEB-INF/hr.xsd" />
 <property name="portTypeName" value="HumanResource" />
 <property name="locationUri" value="http://localhost:8080/holidayService/" />
 </bean>
 </property>
 </bean>

</beans>

And here is the implementation of com.razvan.hr.ws.HolidayEndpoint. According to Maven customaries, this have to be placed in the src/main/java subdirectory of the project. I have tried to keep the implementation minimal by avoiding further service instantiations, unrelated to Spring-WS:

package com.razvan.hr.ws;

import java.text.SimpleDateFormat;
import java.util.Date;

import org.apache.commons.logging.Log;
import org.jdom.Element;
import org.jdom.JDOMException;
import org.jdom.Namespace;
import org.jdom.xpath.XPath;
import org.springframework.ws.server.endpoint.AbstractJDomPayloadEndpoint;

public class HolidayEndpoint extends AbstractJDomPayloadEndpoint {

 private XPath startDateExpression;

 private XPath endDateExpression;

 private XPath nameExpression;

 public HolidayEndpoint() throws JDOMException {
 Namespace namespace = Namespace.getNamespace("hr", "http://mycompany.com/hr/schemas");
 startDateExpression = XPath.newInstance("//hr:StartDate");
 startDateExpression.addNamespace(namespace);
 endDateExpression = XPath.newInstance("//hr:EndDate");
 endDateExpression.addNamespace(namespace);
 nameExpression = XPath.newInstance("concat(//hr:FirstName,' ',//hr:LastName)");
 nameExpression.addNamespace(namespace);
 }

 protected Element invokeInternal(Element holidayRequest) throws Exception {
 SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");
 Date startDate = dateFormat.parse(startDateExpression.valueOf(holidayRequest));
 Date endDate = dateFormat.parse(endDateExpression.valueOf(holidayRequest));
 String name = nameExpression.valueOf(holidayRequest);

 // do something meaningful with the extracted data.
 System.out.println("Start date: "+startDate+" end Date: "+ endDate+" Employee: "+name);
 return null;
 }
}

My final file structure is:

|-- pom.xml
`-- src
 `-- main
   |-- java
   |   `-- com
   |       `-- razvan
   |           `-- hr
   |               `-- ws
   |                   `-- HolidayEndpoint.java
   `-- webapp
     `-- WEB-INF
        |-- hr.xsd
        |-- spring-ws-servlet.xml
        `-- web.xml

The web.xml is pretty standard for Spring applications:

<?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>Spring test application</display-name>

 <servlet>
 <servlet-name>spring-ws</servlet-name>
 <servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>
 </servlet>

 <servlet-mapping>
 <servlet-name>spring-ws</servlet-name>
 <url-pattern>/*</url-pattern>
 </servlet-mapping>

</web-app>

This is the whole Web Service application. In order to run the application try from the command line:

mvn clean install jetty:run

This will compile the war file and start an instance of the jetty web server.

By accessing the address: http://localhost:8080/holidayService/holiday.wsdl you can see the generated WSDL associated to your described web service. While leaving the jetty running, you may attempt to create a client, in order to see the message printed within the invokeInternal method. Following it will be described a Java client, but it is possible to build your client using any other language or platform.

Using the Eclipse wizard create a new empty Java project, than create using the wizard a new “Web Service Client”. Provide the address of the wsdl and you will have a bunch of Java classes describing your web service and the required XML parsers dependencies in your newly created project. Create a new main class in the default package named TestWs.java, with the following content:

import java.math.BigInteger;
import java.util.Date;

import com.mycompany.hr.schemas.EmployeeType;
import com.mycompany.hr.schemas.HolidayRequest;
import com.mycompany.hr.schemas.HolidayType;
import com.mycompany.hr.schemas.HumanResource;
import com.mycompany.hr.schemas.HumanResourceServiceLocator;

public class TestWs {
 public static void main(String[] args) {
 try {
 HumanResourceServiceLocator loc = new HumanResourceServiceLocator();
 HumanResource myserv = loc.getHumanResourcePort();

 HolidayType ht = new HolidayType(new Date(), new Date());
 EmployeeType et = new EmployeeType(new BigInteger("100"), "Razvan",
 "Popovici");
 HolidayRequest req = new HolidayRequest(ht, et);

 myserv.holiday(req);
 } catch (Exception e) {
 e.printStackTrace();
 }
 System.out.println("OK!");

 }
}

Run the class, and you will be able to observe the message in the maven window.

A few conclusions of the test are:

- Spring-WS is a great approach if the schema definitions of the data model already exists.

- The required xalan dependency is a bug in Spring-WS dependency requirements, fortunately Maven made possible the correction.

- The element wsdl:definitions is optional, the tutorial worked without it as well.

At last I also decided to join the maven[1] bandwagon, I will start using maven for managing my projects. Convention over configuration  sounds  indeed a nice idea.  When I first heard about maven  I didn’t have a good “feeling” about it, may be because I was too comfortable with ant and believe to be able to achieve any task with it. But now after reading some documentation and articles about maven, I came to realise it is completely new paradigm than ant. In my opinion the best aspect of maven is that you always have the big picture of your project in mind instead of a small task or operation to be done.  I started liking maven and  also started learning it.  For reference I have started following  Maven: The Definitive Guide[2]. Another great advantage could be that if you know maven and a join a new team which also uses maven for project management, you don’t have to spend hours or may be days trying to figure out the structure of their project and being able to build it.

Although I started liking maven, sometimes it feels like a strange tool, where you have to configure a lot to achieve your goal. if you want some custom stuff in your project. I also find it annoying that by default the compiler-plugin assumes you want to build for java 1.4 or java 1.3.  Moreover, because there are always so called sensible or obvious defaults assumed, in maven world, not all the obvious defaults are obvious to you and you have to know the documentation well to be able to know what those defaults are. and how you can achieve something different. It feels somewhat like javadocs, until you get used to the apis you need frequently, you have to rely on auto-completion of your IDE or have the javadoc always open. There is no wonder that the second part of the book, I mentioned contains only the maven reference.

But, yes, I am here to talk about the quirk of maven which I encountered during my learning process. I am just a maven beginner, so may be this is normal behavior, but I don’t think so.

So, while starting to learn maven, I started with a contrived JavaEE application (brave huh), which is taken as example in the very good book EJB 3 in Action[3]. I searched the net and found out about the maven archetype j2ee-simple here. I used following commandline to generate the stubs of a simple JavaEE project, actually I was interested in the standard directory structure.

mvn archetype:create -DgroupId=com.hardik -DartifactId=ActionBazaar -DarchetypeArtifactId=maven-archetype-j2ee-simple

The project was created perfectly, but by default it was not compiling. When I executed mvn intall I had following errors.

$ mvn install
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).

Project ID: unknown

Reason: Could not find the model file '/home/hardik/projects/ActionBazaar/site'. for project unknown

[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Could not find the model file '/home/hardik/projects/ActionBazaar/site'. for project unknown
    at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:432)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:300)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
    at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
    at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
    at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
    at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file '/home/hardik/projects/ActionBazaar/site'. for project unknown
    at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1575)
    at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
    at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200)
    at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:632)
    at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:515)
    at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:588)
    at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:419)
    ... 12 more
Caused by: java.io.FileNotFoundException: /home/hardik/projects/ActionBazaar/site (No such file or directory)
    at java.io.FileInputStream.open(Native Method)
    at java.io.FileInputStream.<init>(FileInputStream.java:106)
    at hidden.org.codehaus.plexus.util.xml.XmlReader.<init>(XmlReader.java:124)
    at hidden.org.codehaus.plexus.util.xml.XmlStreamReader.<init>(XmlStreamReader.java:67)
    at hidden.org.codehaus.plexus.util.ReaderFactory.newXmlReader(ReaderFactory.java:118)
    at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1570)
    ... 18 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Thu Jul 09 18:44:31 CEST 2009
[INFO] Final Memory: 1M/4M

[INFO] ------------------------------------------------------------------------

It is talking about some model file for the site module. The site module is generally the “website” of your project that maven generates just by looking at your pom.xml file. I removed the site module from the module list of the pom file and it started working. But I still wonder why the default project structure doesn’t build. I am sure this is incorrect behavior.

If someone has had the same problem, and was able to fix, please let me know.

References:

1. Apache-maven
2. Maven: The Definitive Guide
3. EJB 3 in Action

Earlier I blogged about my recent experiences with Apache Maven, i.e. Apache Maven vs. Apache Ant.  Several of the major issues were had were:

• Performance – Maven’s performance (compared to Apache Ant) is horrible.  It repeats steps throughout the build (doesn’t skip anything and worse repeats some steps).  It’s constantly calling out to the Internet looking for  SNAPSHOT’s (per target/goal) as if somehow it magically changed mid-build.  A hack for repeated SNAPSHOT searches is to review all dependencies you have to remove as many SNAPSHOT’s on 3rd party components (wherever possible).  This isn’t foolproof as some of your dependencies might have dependencies on SNAPSHOT’s.  (For the ultimate hack you could tweak all of the POM’s in question but that’s painful and error prone and the next time you update something it could all get blown away.)  Another hack is to shut off your Internet connection.  The lack of a connection makes Maven stop looking (brilliant).
• Scalability – Maven is a memory hog. The more complex (i.e. more nested components leveraging the reactor) your build process becomes the more memory consumed.  Here you need to tweak MAVEN_OPTS environment variable.

I was recently able to make some performance improvements to help Apache Maven, i.e.

• Got a new laptop App MacBook Pro (2.6Ghz, 4 G RAM, HD w 7200 RPM)… not sure what exactly has sped things up but I suspect its the hard drive (as everything else is marginally better, i.e. 0.30 GHz faster CPU, 1G more RAM).
• Tweaked the MAVEN_OPTS 

Originally I had the following MAVEN_OPTS settings: setenv MAVEN_OPTS “-Xmx640m” but I was getting errors for “out of perm space” so I used the following MAVEN_OPTS settings:

setenv MAVEN_OPTS “-Xms128m -Xmx640m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=640m -Xverify:none”

But as the number of components were built it locked the system.  I suspect the issue is the garbage collection settings.  So I reduced the MAVEN_OPTS settings to the following:

setenv MAVEN_OPTS “-Xms128m -Xmx640m -XX:MaxPermSize=640m”

This immediately helped get further in the build process.  Eventually it ran out of heap memory so now the MAVEN_OPTS settings are as follows:

setenv MAVEN_OPTS “-Xms128m -Xmx1280m -XX:MaxPermSize=640m” which seems to have done the trick.  I’m now able to do complete builds (mvn clean install) with these settings without doing hacks like shutting off my network connections, tweaking POM’s, etc.

But… need to get this working for creating sites, (i.e. mvn site) as well as getting this running with integration tests… (I have quite a few).

In the meantime I’ve been reading the Ant In Action book (which is quite good).  I’ve basically re-examined my entire Ant build process (and theory).  So I’ve started creating scripts from scratch trying to incorporate concepts from the book, i.e.

• Declaring “beaucoup” ANT properties that can be overridden in a property file (or passed in properties from parent ANT scripts).
• Importing ANT tasks (both life cycle tasks that can be overridden as needed as well as common functionality).
• Potentially leveraging IVY for dependency management.
• Potentially leveraging SmartFrog for deployment management (conceptually cool project).
• Getting JBoss Seam’s testing to work with ANT (shouldn’t be an issue as JBoss Seam uses ANT primarily).

Fingers crossed but making progress…

For doing software builds in the Java world… most people use either Ant or Maven.  I’ve used both…

From a requirements perspective I need a continuous integration/build process that can do the following:

• Dependency Management – In one place identify the components and their versions that are included in this project.  Ideally the same dependency management system can deal with child dependencies automatically.
• Support some form of reuse across the components (in terms of the build scripts, ideally there’s no large scripts that have redundant text across the commands, difficult to maintain/keep consistent)
• Support for hierarchical projects composed of numerous components (must scale and allow complexity).
• Allow quick builds (most perform)
• Ideally create a project Web site (documentation)
• At least create project reports per component.

I started in the Ant world, i.e. oodles of ANT scripts on big projects.  My main issue was the complexity of the ANT scripts after awhile and the lack of reuse when you had a multi-component.  But it was fast and it could do anything, i.e. powerful.  I experimented on/off with Maven over the years.  Finally got it working this year.  Everything as advertised except really slow when there’s an Internet connection (and just slow in general).  And needed to break large projects up and build them separately (or them crash early, i.e. PermSpace errors).  With command lines like the following:

MAVEN_OPTS “-Xms128m -Xmx640m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=640m -Xverify:none”

It didn’t crash on the mini-builds… but when trying to build everything it would just slow down and ultimately lock the machine.  I was really attracted to the Development Web site that was created with mvn site but if the system can’t perform nor scale… it’s not worth it.  Looking at Seam and Hibernate.. they appear to get by just fine.  And then there’s trying to get the JBOSS Embedded Server running in Maven…  I’ve searched alot/experimented and just not sure what I’m missing there.  Time to thrown in the towel.  So now I’m going to move back to Ant.  In the past few years… it appears as though Ivy has caught on so perhaps Dependency Management.  Appears to be some templating/reuse concepts (although that may have been there awhile and I overlooked it).  Not sure how much can be templated so will be interested to investigate.

So in retrospect… Maven is nice for small projects.  Mine appears massive (i.e. many components, a lot of code generation, etc.).  So time to go back to Apache Ant.  Also need to get a wiki like http://www.SeamFramework.org and http://in.relation.to (i.e. the documentation posted to Al Gore’s Internet).

It is widely known that any published text must pass the “so what?” quality gate. The following post tries to extend this to software.

Imagine that you have a scripted language code (in my sample, apache maven) which allows the caller to provide values to one or more variables.

Within the pom.xml file, there is a line like:

<commandlineArgs>${data.directory}</commandlineArgs>

And the caller is able to provide a value to the variable, with the call

mvn install -Ddata.directory=/home/theuser

So far so good, but what about if the structure is much complicated, and the user misspells the variable name in the command line call? In this case, no error or warning is issued, the variable uses the default value. This only because the interpretor is unable to question “so what?” the command line.

The implementation of such a feature is difficult: the software should be able to keep track of the variables, their definition source and the amount of accesses. If an user defined variable had no accesses then is as good candidate for the “so what?”