Das Bauen und Ausliefern von normalen und eigenständigen Java Anwendungen die nicht in einem Webcontainer oder Applikationserver laufen sollen kann sich als schwierig erweisen. Die größten Probleme beim Erzeugen der Releases sind dabei die folgenden Punkte:

• 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

Am 29. Oktober 2009 wird in Frankfurt am Main der Confluence Community Day 2009 stattfinden. Im Vorfeld haben wir Kurz-Interviews mit den Referenten geführt. Heute nun das Gespräch mit Tino Winkler von Communardo, der einen Vortrag zum Thema “Wie lässt sich ein vollständiger Import von Inhalten mit Metadaten nach Confluence realisieren?” halten wird.

Dirk Röhrborn:

Wir freuen uns auf Deinen Vortrag auf dem Confluence Community Day 2009. Was möchtest Du den Teilnehmern hauptsächlich vermitteln?

Tino Winkler:

Möchte man Daten in eine bestehende Confluence Instanz importieren, steht man vor der Aufgabe nicht nur die entsprechenden Inhalte (Seiten, News, Kommentare) generieren zu müssen, sondern auch deren Metadaten (Autor, Zeitpunkt der Erstellung, …). Ich möchte zeigen, wie dies unter Verwendung der Confluence API realisiert werden kann und dabei auf ein paar Fallstricke hinweisen.

Dirk Röhrborn:

Wie siehst Du die Bedeutung der Confluence-Technolgie für Unternehmen in den nächsten Jahren?

Tino Winkler:

In Unternehmen gibt es immer Wissen das über Projektgrenzen hinweg von Bedeutung ist. Um dieses zu dokumentieren und aktuell zu halten sind Wikis auf Grund ihrer Einfachheit sehr gut geeignet. Ob sich Wikis wie Confluence im unternehmerischen Umfeld auf Dauer etablieren können, hängt wohl auch stark davon ab, ob sich diese Art der Dokumentation von Wissen durchsetzten kann.

Darüber hinaus wird gerade Confluence durch die stärkere Integration mit anderen Atlassian-Produkten für Unternehmen in der IT-Branche zusätzlich an Reiz gewinnen.

Dirk Röhrborn:

Welche Bedeutung haben Wikis für Dich ganz persönlich?

Tino Winkler:

Wikis sind für mich eine ideale Möglichkeit ohne großen redaktionellen Aufwand Wissen zu sammeln und aktuell zu halten. Durch diese Einfachheit sind Nutzer eher bereit sich zu beteiligen. Auf diese Weise wird Wissen konserviert, welches sonst wohl verloren gehen würde.

Dirk Röhrborn:

Welche Trends siehst Du für den Einsatz von Confluence in nächster Zeit?

Tino Winkler:

Ich denke, dass vorallem die angekündigte Unterstützung von OpenSocial-Gadgets über ein Dashboard in einer der nächsten Confluence-Versionen interessante Impulse geben wird. Damit könnte Confluence dann auch zur Aggregation von Informationen aus anderen Systemen verwendet werden.

Dirk Röhrborn:

Eine Frage zum Schluss: Was erhoffst Du Dir selbst vom Confluence Community Day 2009 mit nachhause zu nehmen?

Tino Winkler:

Mich interessiert wie andere ihr Confluence nutzen und ob ihnen dabei eventuell noch Funktionen fehlen . Außerdem hoffe ich natürlich Kontakte zu anderen Entwicklern knüpfen zu können.

Dirk Röhrborn:

Vielen Dank für das Gespräch. Wir freuen uns auf Deinen Vortrag auf dem Confluence Community Day.

Damit Confluence seinen vollen Funktionsumfang erreichen kann, sollte dem System ein Onlinezugang ermöglicht werden. Dadurch kann unter anderem das Plugin-Repository genutzt werden, mittels welchem die von Atlassian bereitgestellten Plugins bequem auf dem eigenen System installiert und verwaltet werden können. Aber auch zahlreiche Plugins basieren auf einer bestehenden Onlineverbindung. So können zum Beispiel durch das RSS-Feed-Macro sowohl externe als auch innerhalb von Confluence generierte RSS-Feeds auf eigenen Seiten eingebunden werden. Mit dem IM-Presence-Plugin können Confluence-Nutzer ihren Onlinestatus in verschiedenen Instant Messenger – Systemen auf einer Seite anzeigen lassen. Dieses Plugin ist besonders für persönliche Seiten und Blogs interessant.

Wenn Confluence kein direkter Internetzugang ermöglich werden kann (z.B. wenn das System innerhalb eines internen Netzes betrieben wird), besteht die Möglichkeit einen WebProxy anzugeben. Dafür muß im Startscript des Applikationsservers (beispielsweise eine Datei “catalina.bat” im “bin” Verzeichnis eines Tomcat-Applikationsservers) die Variable

JAVA_OPTS

mit dem Parameter

set JAVA_OPTS="-Dhttp.proxyHost=proxy.example.com -Dhttp.proxyPort=3128"

versehen werden.