Der große Vorteil dieses Frameworks  ist, dass die Erzeugung der Klassen sehr leicht ins Maven eingebunden werden kann und das das Persistieren nur wenige Zeilen Code nötig macht.

Einbindung in Maven

Zum erzeugen der Beans ist eigentlich nur die Dependency für Hyperjaxb3 der bestehenden pom.xml hinzuzufügen:

Der Aufruf der Codegenerierung sollte sinnvollerweise in einem Profile-Zweig erfolgen, damit nicht bei jedem Compile die Klassengenerierung neu angestoßen wird.

Die Generierung kann dann per Aufruf des Profiles erfolgen: mvn install -Phyperjaxb

Objekt erzeugen und persistieren

In der Anwendung kann dann das Objekt aus dem XML mithilfe des Unmarshallers erzeugt …

und vom Entitymanager persistiert werden:

Optional kann am Unmarshaller noch die Validierung eingeschaltet werden:

Hyperjaxb3 kann bei der Erzeugung von komplexen Datenmodellen aus einer vogegebenen XSD sehr hilfreich sein. Es werden alle Relations, die persistence.xml mit allen nötigen Konfigurationen und die ObjectFactory erzeugt.

• es müssen die benötigten Bibliotheken aufgelöst und mit in des Release gepackt werden
• die Java Applikation muss in den meisten Fällen auf dem Zielsystem als Dienst laufen (Deamon)
• das Erstellen und Packen des Releases sollte automatisiert erfolgen

Das Maven 2 Plugin appassembler zielt auf diesen Anwendungsfall ab und ermöglicht

• das automatisierte Erstellen von Skripten zur einfachen Ausführung der Applikation
• das Erzeugen von Releases die es ermöglichen, die Java Anwendung als Dienst zu betreiben
• die Erzeugung von Repositories die alle nötigen Bibliotheken für die Anwendung enthalten.

Die Konfiguration des Plugins ist aber leider nicht ganz so einfach da die Dokumentation eher schlecht ist und ich auch auf Bugs im Plugin selber gestoßen bin.

Im Folgenden ist  eine Konfiguration als Beispiel aufgelistet die eine Deamonapplikation erzeugt.  Um die Applikation als Dienst betreiben zu können wird vom Plugin  der weit verbreitete Java Service Wrapper eingesetzt.

Beispielkonfiguration

<plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>appassembler-maven-plugin</artifactId>
 <configuration>
   <repositoryLayout>flat</repositoryLayout>
   <includeConfigurationDirectoryInClasspath>true</includeConfigurationDirectoryInClasspath>
   <target>${project.build.directory}/appassembler</target>
     <daemons>
       <daemon>
         <id>daemon-app</id>
         <mainClass>de.communardo.appassembler.Launcher</mainClass>
         <commandLineArguments>
           <commandLineArgument>start</commandLineArgument>
         </commandLineArguments>
         <platforms>
           <platform>jsw</platform>
         </platforms>
         <jvmSettings>
           <extraArguments>
             <extraArgument>-server</extraArgument>
           </extraArguments>
           <initialMemorySize>64M</initialMemorySize>
           <maxMemorySize>512M</maxMemorySize>
           <systemProperties>
             <systemProperty>property=value</systemProperty>
           </systemProperties>
         </jvmSettings>
         <generatorConfigurations>
           <generatorConfiguration>
             <generator>jsw</generator>
             <includes>
               <include>linux-x86-32</include>
               <include>linux-x86-64</include>
             </includes>
             <configuration>
               <property>
                 <name>configuration.directory.in.classpath.first</name>
                 <value>conf</value>
               </property>
               <property>
                 <name>set.default.REPO_DIR</name>
                 <value>lib</value>
               </property>
               <property>
                 <name>wrapper.logfile</name>
                 <value>logs/wrapper.log</value>
               </property>
               <property>
                 <name>wrapper.logfile.maxsize</name>
                 <value>10m</value>
               </property>
               <property>
                 <name>wrapper.logfile.maxfiles</name>
                 <value>5</value>
               </property>
               <property>
                 <name>wrapper.console.title</name>
                 <value>appassembler application</value>
               </property>
               <property>
                 <name>run.as.user.envvar</name>
                 <value>root</value>
               </property>
               <property>
                 <name>wrapper.working.dir</name>
                 <value>d:\</value>
               </property>
               <property>
                 <name>set.default.APP_BASE</name>
                 <value>d:\</value>
               </property>
             </configuration>
           </generatorConfiguration>
         </generatorConfigurations>
       </daemon>
     </daemons>
   </configuration>
   <executions>
     <execution>
       <id>create-release</id>
       <goals>
         <goal>create-repository</goal>
         <goal>generate-daemons</goal>
       </goals>
       <configuration>
         <assembleDirectory>${project.build.directory}/appassembler/jsw/daemon-app</assembleDirectory>
         <repoPath>lib</repoPath>
       </configuration>
       <phase>package</phase>
     </execution>
   </executions>
</plugin>

Parameter

Trotzdem kann es wichtig sein, dass die Bundles unabhängig von Eclipse in Maven gebaut werden können, z.B. um komplette Releases mit Tokenersetzung für verschiedene Umgebungen zu bauen. Für Maven2 existiert das Felix Bundle Plugin (http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html), welches fertige Bundles generieren kann.

Da sich die Verszeichnisstrukturen des Eclipse-Plugin-Development-Tools und eines Standard-Maven2-Projektes sehr unterscheiden, wird hier ein Weg beschrieben, wie beide Welten vereinigt werden können.

Als Verzeichnisstruktur des Maven-Projektes wird folgendes vorausgesetzt:

- src

- main

- bundle

- META-INF

- Manifest.MF

- java

Innerhalb von Eclipse muss aber das META-INF-Verzeichnis im Wurzelverzeichnis des Projektes liegen, damit es als Bundle gebaut wird. Deshalb legen wir das Plugin-Projekt innerhalb des Bundle-Ordners an und importieren alle benötigten Resourcen (in diesem Fall nur den java-Ordner) über Verlinkung in das Projekt. Dafür erstellt man einen neuen Ordner und selektiert unter Advanced die Checkbox Link to Folder in file system. Dann wählt man den Java-Ordner und fügt ihn zum Projekt hinzu. Über das Kontext-Menü -> Build Path -> Use as source folder kann dieser Ordner  als Quellordner markiert werden.

Die Verzeichnisstruktur im Eclipse-Projekt sieht jetzt folgendermaßen aus:

- META-INF

- Manifest.MF

- java (Verlinkt)

Jetzt muss nur noch das Maven-Plugin so eingerichtet werden, daß es die Bundle-Konfiguration aus der vom Eclipse erzeugten Manifest-Datei übernimmt. Das kann z.B. so aussehen:

<plugin>

<groupId>org.apache.felix</groupId>

<artifactId>maven-bundle-plugin</artifactId>

<extensions>true</extensions>

<executions>

<execution>

<id>bundle</id>

<phase>package</phase>

<goals>

<goal>bundle</goal>

<goal>install</goal>

</goals>

</execution>

</executions>

<configuration>

<instructions>

<_failok>true</_failok>

<_include>src/main/bundle/META-INF/MANIFEST.MF</_include>

<Include-Resource>{maven-resources},META-INF/spring=src/main/bundle/META-INF/spring</Include-Resource>

</instructions>

</configuration>

</plugin>

Das _include -Tag bewirkt, dass für die Bundle-Generierung die von Eclipse erzeugte Manifest-Datei verwendet wird. Leider wird in Dieser der Klassenpfad Einträge enthalten, die im erzeugten Bundle nicht mehr vorhanden sind, z.B. der bin-Ordner, in welchem die kompilierten Klassen liegen. Das Bundle-Plugin bricht an dieser Stelle ab, obwohl ungültige Klassenpfad-Einträge in Equinox nicht zu Fehlern führen. Der einfachste Weg, dieses Problem zu umgehen, ist _failok auf true zu setzen. Eleganter wäre es, den Klassenpfad-Eintrag vorher zu manipulieren. Wichtig ist nur, dass der Klassenpfad-Eintrag ./ existiert, weil das Bundle-Plugin alle Klassen im Wurzel-Verzeichnis des Bundles ablegt.

Allerdings kann nicht davon ausgegangen werden, dass sich das Bundle auf Anhieb in einem extern gestarteten equinox genauso verhält, wie in Eclipse, da Eclipse zahlreiche Umgebungsvariablen setzt, die von den Default-Werten abweichen. Sollten also ClassNotFoundExceptions bei Klassen auftreten, welche normalerweise zur JRE gehören (z.B. org.w3c.dom.Node) und innerhalb von Eclipse nicht als Dependency eingebunden werden müssen, dann lohnt sich ein Blick in die System-Properties.

Properties prop = System.getProperties();
for (Object k : prop.keySet()) {
System.out.println(k + ” – ” + prop.getProperty(k.toString()));
}

Gibt alle Properties aus. Eine Beschreibung der einzelnen Parameter befindet sich hier

Wichtig sind vor allem die Parameter osgi.compatibility.bootdelegation und org.osgi.framework.system.packages.

Wenn eine solche Entwicklungsumgebung eingerichtet wurde, kann der Buildprozess eines Plugins noch weiter vereinfacht werden. Dafür stellt Atlassian das Plugin Developer Kit for Maven2 (kurz PDK) zur Verfügung. Dabei handelt es sich um ein Maven-Plugin, welches einfach in der POM des eigenen Projektes eingebunden werden muss und dann automatisch beim Buildprozess heruntergeladen und installiert wird. Ein solcher Aufruf kann z.B. so aussehen:

<plugin>
   <groupId>com.atlassian.maven.plugins</groupId>
   <artifactId>atlassian-pdk</artifactId>
   <executions>
      <execution>
         <phase>package</phase>
         <goals>
            <goal>uninstall</goal>
            <goal>install</goal>
            <goal>rescan</goal>
         </goals>
      </execution>
   </executions>
</plugin>

Dabei können verschiedene Goals angegeben werden, welche hintereinander ausgeführt werden und z.B. das Plugin direkt nach dem kompilieren in einem laufenden Confluence deinstallieren und die neue Version installieren. Eine sinnvolle Reihenfolge wäre z.B. Uninstall – Install – Rescan.

Vorsicht ist allerdings bei der Benutzung des Confluence Trigger Plugin Moduls geboten. Hat man einen Trigger in seiner atlassian-config.xml eingebunden und installiert das Plugin über das PDK direkt in ein laufendes Confluence, sollte nach einem Install kein explizites Enable des Plugins ausgeführt werden. Der Grund dafür ist: der Job wird bereits beim Install angelegt. Bei einem folgenden Enable wird dann erneut versucht, dieser Job anzulegen – was natürlich fehlschlägt und mit einer ObjectAlreadyExistsException quittiert wird. Ein Install und ggf. Rescan ist in diesem Fall also ausreichend.

Nach ein paar Recherchen habe ich mich für die Verwendung des freien Retrotranslator-Tools entschieden und eine Proof-Of-Concept-Implementierung realisiert. Retrotranslator kann sowohl zur Compile-Zeit als auch zur Laufzeit den Java2 5.0 Bytecode in Java2 1.4 Bytecode umwandeln. Für den eigenen Code habe ich mich für die Umwandlung zur Compilezeit entschieden und für verwendeten Code Dritter für die Umwandlung zur Laufzeit (Just in Time Compilierung).

Nun zur praktischen Umsetzung mit Maven2:

Das POM des Codegenerierungsprojektes sieht folgendermaßen aus:

<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>de.communardo.techblog</groupId>
  <artifactId>demoxfiregen</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>Generierter XFire-Code fuer Communardo Techblog</name>

  <build>
    <plugins>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>xfire-maven-plugin</artifactId>
        <version>1.0-SNAPSHOT</version>
        <executions>
          <execution>
            <goals>
              <goal>wsgen</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <package>
            de.communardo.techblog.services
          </package>
          <profile />
          <binding />
          <outputDirectory>
            ${project.build.directory}/generated-sources/xfire
          </outputDirectory>
          <wsdls>
            <wsdl>
              ${basedir}/src/main/resources/TechblogDemoService.wsdl
            </wsdl>
          </wsdls>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>retrotranslator-maven-plugin</artifactId>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>translate-project</goal>
            </goals>
            <configuration>
              <classifier>jdk14</classifier>
              <attach>true</attach>
              <embed>net.sf.retrotranslator</embed>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

  <dependencies>
    <dependency>
      <groupId>org.codehaus.xfire</groupId>
      <artifactId>xfire-jaxb2</artifactId>
      <version>1.2.5</version>
    </dependency>
  </dependencies>
</project>

Der erste Plugin-Aufruf setzt die Java-Version auf 1.5, der Zweite generiert den Java-Code aus einer WSDL und der dritte generiert in der package-Phase von Maven ein Java2 1.4 kompatibles JAR-Archiv mit dem Classifier jdk14. Mit

mvn install

wird alles gebaut und ins lokale Maven-Repository installiert.

Im Java2 1.4-Projekt wird das generierte JAR in den Dependencies so referenziert:

    <dependency>
      <groupId>de.communardo.techblog</groupId>
      <artifactId>demoxfiregen</artifactId>
      <version>1.0-SNAPSHOT</version>
      <classifier>jdk14</classifier>
    </dependency>

Um alle Abhängigkeiten, die von XFire und den JAXB2-Klassen benötigt werden zu erfüllen und den Retrotranslator Just-In-Time-Compiler (JIT) vefügbar zu machen, wurden noch folgende Dependencies in das Ziel-POM eingetragen:

    <dependency>
      <groupId>net.sf.retrotranslator</groupId>
      <artifactId>retrotranslator-transformer</artifactId>
      <version>1.2.1</version>
    </dependency>
    <dependency>
      <groupId>javax.xml.parsers</groupId>
      <artifactId>jaxp-api</artifactId>
      <version>1.4</version>
    </dependency>
    <dependency>
      <groupId>com.sun.org.apache</groupId>
      <artifactId>jaxp-ri</artifactId>
      <version>1.4</version>
    </dependency>
    <dependency>
      <groupId>xerces</groupId>
      <artifactId>xercesImpl</artifactId>
      <version>2.8.1</version>
    </dependency>

Damit das Ganze dann zur Laufzeit funktioniert muss beim Start der Applikation der Retrotranslator JIT genutzt werden, das geschieht in dem man die JVM-Kommandozeile folgendermaßen aufbaut:

java <JVM-Parameter> net.sf.retrotranslator.transformer.JITRetrotranslator <Main-Klasse> <Anwendungsparameter>

Leider gibt es bei Projekten mit mehrenen Modulen häufig Probleme in der Verlinkung der generierten Html-Seiten. Da die Super-Pom zwar alle Sub-Modules kennt aber nicht umgekehrt, sind die Module auf der Projekt-Page auch nur in eine Richtung verlinkt. Möchte man nun zu einem Parent-Modul navigieren, muss man entweder die Browser-Hierarchie bemühen oder die Startseite erneut aufrufen.

Direkte Modulverlinkung

Die Lösung für dieses Problem ist die site.xml. In dieser Datei kann das Aussehen und die Navigation der Projektseite individuell angepasst werden. Den generellen Aufbau der site.xml findet man hier. Damit nun die Verlinkung funktioniert muss in jedem Modul im Verzeichnis src/ ein Ordner site, zusammen mit der Datei site.xml angelegt werden. Eine leere site.xml erzeugt eine blank-page, daher muss für die Standardfunktionalität folgender Content eingebunden werden:

<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="Maven">
  <body>
    <menu ref="parent"/> <!-- Erzeugt Link zum Parent-Modul-->
    <menu ref="modules"/>
    <menu ref="reports"/>
  </body>
</project>

Mit mvn site-deploy werden nun die zugehörigen Projektseiten erzeugt. Ein Aufruf der Startseite überrascht noch nicht, es werden wie gewohnt alle Module angezeigt.

Auf den Seiten der Sub-Modules hingegen, erscheint nun ein Link zum jeweiligen Parent-Modul oben in der Navigationsleiste.

 Krümelpfad Verlinkung

Die direkte Verlinkung erfüllt zwar ihren Zweck, ist aber gerade bei mehreren Hierarchiestufen nicht gerade praktisch. Besser wäre da doch ein Krümelpfad mit dem man beliebig zwischen den Seiten wechseln kann. Wieder hilft dabei die site.xml

<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="Maven">
  <body>
    <breadcrumbs>
      <item name="<ModulName>" href="index.html" mce_href="index.html"/>
    </breadcrumbs>
    <menu ref="modules"/>
    <menu ref="reports"/>
  </body>
</project>

In dem Item-Tag wird dabei nur der Name des aktuellen Moduls eingetragen und als href die index.html. Maven baut dann automatisch den Pfad synchron zur Modulhierarchie zusammen. Die nachfolgenden Abbildungen zeigen eine Projektseite mit drei Hierarchieebenen.

                        ]]> http://www.communardo.de/home/techblog/2007/12/05/maven-2-multi-modules-project-site/feed/ 0 http://www.communardo.de/home/techblog/2007/11/15/properties-und-spring/ http://www.communardo.de/home/techblog/2007/11/15/properties-und-spring/#comments Thu, 15 Nov 2007 18:59:16 +0000 Torsten Lunze http://www.communardo.de/home/techblog/2007/11/15/properties-und-spring/ Bei der Verwendung von Spring stellt sich im Buildmanagement die Frage wie mit Properties umgegangen wird. So hat jeder Test-, Live- und Entwicklungsserver seine eigene Datenbank oder andere unterschiedliche Einstellungen. Eine oft gewählte Variante ist die Ersetzung der Properties durch den Buildprozess. Dies hat allerdings den Nachteil, dass für eine Änderung der Properties der Buildprozess neu ausgeführt werden muss.

Mit Spring bietet sich dabei eine Alternative: Hier kann ein Propertyfile welches z. B. im Classpath liegt eingebunden werden:

<bean id="propertyPlaceholder" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="classpath:hibernate.properties" />
</bean>

Die Properties, die dann in dem File ‘hibernate.properties’ definiert sind, können innerhalb der Springkonfiguration genutzt werden:

...
<property name="hibernateProperties">
<props>
<prop key="hibernate.show_sql">${hibernate.show_sql}</prop>
<prop key="hibernate.dialect">${hibernate.dialect}</prop>
<prop key="hibernate.hbm2ddl.auto">${hibernate.hbm2ddl.auto}</prop>
...
</props>
</property>
...


Das Property File selbst ist dabei einfach wie erwartet:

hibernate.show_sql=true
hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
hibernate.hbm2ddl.auto=update

Die neue Anforderung war, dass Attribute aus der DTD auf andere Typen als String gemappt werden sollen. Da DTDs keine Typisierung wie XML-Schema kennen, muss dies mit einem Mapping-File geschehen. Das Maven2-Plugin aus dem gestrigen Artikel war leider mit dem Mapping der Attribute überfordert.

Jetzt wurde das Maven2-JAXB-Plugin von java.net verwendet, damit ändert sich die pom.xml folgendermaßen:

<?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>de.mms-dresden</groupId>
  <artifactId>hsp-search-gen</artifactId>
  <name>Hilfe- und Support-Portal generierter Code fuer die Suche</name>
  <version>0.1-SNAPSHOT</version>
  <parent>
    <groupId>de.mms-dresden</groupId>
    <artifactId>hsp</artifactId>
    <version>0.1-SNAPSHOT</version>
  </parent>
  <description>Generierter Code fuer die Suche im Hilfeportal</description>
  <build>
    <plugins>
      <plugin>
        <groupId>org.jvnet.jaxb2.maven2</groupId>
        <artifactId>maven-jaxb2-plugin</artifactId>
        <executions>
          <execution>
            <goals>
              <goal>generate</goal>
            </goals>
            <configuration>
              <generateDirectory>${project.build.directory}/generated-sources/jaxb</generateDirectory>
              <extension>true</extension>
              <schemaLanguage>DTD</schemaLanguage>
              <schemaIncludes>
                <schemaInclude>*.dtd</schemaInclude>
              </schemaIncludes>
              <bindingIncludes>
                <bindingInclude>*.jaxb</bindingInclude>
              </bindingIncludes>
              <verbose>true</verbose>
              <args>
                <arg>-Xinject-listener-code</arg>
              </args>
            </configuration>
          </execution>
        </executions>
        <dependencies>
          <dependency>
            <groupId>org.jvnet.jaxb2-commons</groupId>
            <artifactId>property-listener-injector</artifactId>
            <version>1.0</version>
          </dependency>
        </dependencies>
      </plugin>
    </plugins>
  </build>

  <repositories>
    <repository>
      <id>maven2-repository.dev.java.net</id>
      <url>http://download.java.net/maven/2/</url>
    </repository>
  </repositories>

  <pluginRepositories>
    <pluginRepository>
      <id>maven2-repository.dev.java.net</id>
      <url>http://download.java.net/maven/2/</url>
    </pluginRepository>
  </pluginRepositories>

  <dependencies>
    <dependency>
      <groupId>javax.xml.bind</groupId>
      <artifactId>jaxb-api</artifactId>
    </dependency>
  </dependencies>
</project>

Bei der Angabe der Repository-Pfade muss man aufpassen, weil die Angaben auf der Projektseite des Plugins inzwischen nicht mehr stimmen. Stattdessen mussten die Pfade aus der Repositoryseite von java.net verwendet werden.

Die Dependency-Versionen sind jetzt im Parent-POM definiert, entsprechen aber den Versionen aus dem gestrigen Beitrag.

Das Mapping mappt jetzt das Attribut HITCOUNT des Elements NAVIGATIONENTRY auf den Java-Typ int (genauer gesagt den Wrapper Integer um auch null-Werte darstellen zu können) und sieht jetzt folgendermaßen aus:

<?xml version="1.0" ?>
<!--
	The syntax of the binding file for DTD is defined in the JAXB EA.
	See vendorSchemaLangs.html for details.
-->
<xml-java-binding-schema xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
  xmlns:ci="http://jaxb.dev.java.net/plugin/listener-injector">

  <!-- specify the package name for the generated code -->
  <options package="de.mms_dresden.mip.hsp.base.services.search" />
  <xjc:serializable/>

  <element name="NAVIGATIONENTRY" type="class">
    <attribute name="HITCOUNT" convert="int" />
  </element>
</xml-java-binding-schema>

Hier die pom.xml:

<?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>de.mms-dresden</groupId>
  <artifactId>hsp-search-gen</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <description>Generierter Code fuer die Suche im Hilfeportal</description>
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>jaxb2-maven-plugin</artifactId>
        <executions>
          <execution>
            <goals>
              <goal>xjc</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <schemaDirectory>${basedir}/src/main/dtd</schemaDirectory>
          <dtd>true</dtd>
          <xmlschema>false</xmlschema>
          <schemaFiles>FastSearchResult.dtd</schemaFiles>
          <strict>false</strict>
          <verbose>true</verbose>
          <explicitAnnotation>true</explicitAnnotation>
          <packageName>de.mms_dresden.mip.hsp.base.services.search</packageName>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>
    </plugins>
  </build>
  <dependencies>
    <dependency>
      <groupId>javax.xml.bind</groupId>
      <artifactId>jaxb-api</artifactId>
      <version>2.0</version>
    </dependency>
    <dependency>
      <groupId>com.sun.xml.bind</groupId>
      <artifactId>jaxb-impl</artifactId>
      <version>2.0.3</version>
    </dependency>
    <dependency>
      <groupId>com.sun.xml.bind</groupId>
      <artifactId>jaxb-xjc</artifactId>
      <version>2.0.3</version>
    </dependency>
  </dependencies>
</project>

und hier noch das passende File FastSearchResult.xjb:

<?xml version="1.0" encoding="UTF-8"?>
<xml-java-binding-schema>
<options package="de.mms_dresden.mip.hsp.base.services.search" />
<element name="SEGMENTS" type="class" root="true" />
</xml-java-binding-schema>

Die generierten Klassen landen damit in target/generated-sources/jaxb

Heute stelle ich kurz vor, wie man mit Maven 2 und dem XFire-Plugin aus einer WSDL-Datei einen WebService-Client generieren und dann z.B. in einer Testklasse nutzen kann.

Zuerst benötigt man einmal eine WSDL-Beschreibung eines WebService, dafür stelle ich ein kleines Beispiel (xfirefun.wsdl) bereit, es kann aber prinzipiell eine beliebige valide WSDL-Datei genutzt werden.

Alle Dateien die zum Nachvollziehen dieser kurzen Anleitung benötigt werden, liegen in der Zip-Datei xfirefun.zip.

Für den Build mit Maven 2 das XFire-Maven-Plugin benötigt und konfiguriert. Der entsprechende Abschnitt in der pom.xml sieht folgendermaßen aus:

  ...
  <build>
    ...
    <plugins>
      ...
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>xfire-maven-plugin</artifactId>
        <version>1.0-SNAPSHOT</version>
        <executions>
          <execution>
            <goals>
              <goal>wsgen</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <package>de.communardo.ws.xfirefun</package>
          <profile></profile>
          <binding></binding>
          <outputDirectory>${project.build.directory}/generated-sources/client</outputDirectory>
          <wsdls>
            <wsdl>${basedir}/src/main/wsdl/xfirefun.wsdl</wsdl>
          </wsdls>
        </configuration>
      <plugin>
      ...
    </plugins>
    ...
  </build>
  ...

Wenn man nun mvn install aufruft, generiert Maven im Verzeichnis target/client die Webservice-Endpoint- und Datentypklassen. Die eine eigene Clientklasse (XfireFunClientTest.java) dann einfach folgendermaßen nutzen kann:

...
// Client erzeugen
FunClient client = new FunClient();
// Endpoint festlegen und SOAP-Proxy holen
Fun fun = client.getFun(endpoint);
// Request-Objekt erzeugen und befuellen
FunRequest request = new FunRequest();
request.setFileName(filename);
// Remotezugriff absetzen
try {
  FunResponse response = fun.getFile(request);
  FileOutputStream fos = new FileOutputStream(response.getFileName());
  fos.write(response.getData());
} catch (Exception e) {
  e.printStackTrace(System.err);
}
...