Der [Maven Loader] ist eine Erweiterung des [Tomcat] [Application Server] um einen [Maven] Class-Path Loader. Damit können sogenannte [Thin WAR] Files deployed werden, also ein WAR-File das nur die eigentlichen Dateien enthält, Abhängigkeiten werden beim Deployment durch [Maven] nachgeladen und zum Class-Path hinzugefügt.

%%(text-align: center; margin-top: 15px;)
__Laden Sie noch hoch oder deployen Sie schon?
%%

!!!Erklärung
Bisher werden alle JARs in ein WAR-File nach /WEB-INF/lib eingepackt. [Maven Loader] löst dies nun anders und bietet volgende Vorteile:

* __Kleine WAR-Files:__ Kleine Web-Applications hätten eingentlich nur einige hundert Kilobytes, selbst größere Anwendungen überstiegen selten einige Megabyte, wären nicht die JAR-File in dem WAR-Archiv. In der Praxis findet man selten ein WAR-File unter 10 Megabyte, bei JEE-Anwendungen mit JSF, JPA und Spring ist man schnell bei 30 Megabyte. Kommen dann noch einige Drittbibliotheken dazu, kommt man schnell an die 100 Megabyte heran.
* __Deployment:__ Die WARs werden oft durch File-Upload auf den Application-Server gebracht. Selbst wenn sie direkt im Dateisystem oder über das lokale Netzwerk kopiert werden, sind 100 Megabyte dennoch eine große Datenmenge. Mit der eigentlichen Web-Anwendung werden wieder und wieder dieselben Daten übertragen. Auf dem Application-Server wird das WAR dann wieder ausgepackt, weil die enthaltenen JAR-Dateien sonst nicht in den Class-Path eingefügt werden können. Werden mehrere WAR-Dateien deployed, werden die enthaltenen JAR-Dateien unter umständen viele Male in unterschiedliche Deploy-Verzeichnisse kopiert. Das kostet Speicher und Zeit. Mit [Maven Loader] werden nur noch die Nutzdaten upgeloaded und deployed.
* __Build:__ Das bauen eines JAR-Files dauert nur wenige Augenblicke, weil es klein ist und nur die Dateien aus dem Projekt hineingepackt werden. Beim WAR-File geht das Compiling ebenso schnell, dann kommt das Packen der bereits gepackten JAR-Dateien, die Packer und CPU besonders intensiv beschäftigen. Und bei jedem Build dieselben Dateien. Mit [Maven Loader] werden nur noch die Projektdateien compiliert und eingepackt.
* __Maven:__ Inzwischen hat sich [Maven] beim Build durchgesetzt, weil es bequemer ist, den eigentlich Code oder das erzeugte Artifact frei von Dependencies zu halten. Wieso sollte [Maven] also nicht auch am Application Server die Dependencies nachladen?

!!!Lösung
[Intersult] [Maven Loader] ist eine Erweiterung des [Tomcat] [Application Server], sodass dieser die Dependencies eines WAR-Files selbst laden kann. [Maven Loader] arbeitet dabei mit den settings.xml der Maven-Installation zusammen, sodass Proxy-Einträge oder Mirrors benutzt werden kännen. Dies ist gerade in Unternehmensanwendungen häufig der Fall.

!!!Installation
# Zunächst wird eine Tomcat-Instanz installiert. Das System ist bisher mit Tomcat 7 getestet, sollte auch mit Tomcat 6 lauffähig sein.
# Innerhalb der Tomcat-Installation (z.B. C:\Java\apache-tomcat-7.0.42\) wird das [maven.zip] aus dem Anhang ausgepackt.
# Die Datei <tomcat>/conf/catalina.properties wird editiert. Der Eintrag common.loader wird zusätzlich um ${catalina.home}/maven/*.jar erweitert.

Nun ist der [Tomcat] Maven-fähig!

Enthalten sind derzeit die Dateien:

{{{
aether-api-1.11.jar                     maven-settings-3.0.3.jar
aether-connector-wagon-1.13.1.jar       maven-settings-builder-3.0.3.jar
aether-impl-1.11.jar                    nekohtml-1.9.6.2.jar
aether-spi-1.13.1.jar                   plexus-cipher-1.4.jar
aether-util-1.13.1.jar                  plexus-classworlds-2.4.jar
commons-cli-1.2.jar                     plexus-component-annotations-1.5.5.jar
commons-logging-1.1.1.jar               plexus-interpolation-1.14.jar
maven-aether-provider-3.0.3.jar         plexus-sec-dispatcher-1.3.jar
maven-artifact-3.0.3.jar                plexus-utils-2.0.6.jar
maven-compat-3.0.3.jar                  sisu-guice-2.9.4-no_aop.jar
maven-core-3.0.3.jar                    sisu-inject-bean-2.1.1.jar
maven-embedder-3.0.3.jar                sisu-inject-plexus-2.1.1.jar
maven-loader-1.0-SNAPSHOT.jar           wagon-http-lightweight-1.0-beta-7.jar
maven-model-3.0.3.jar                   wagon-http-shared-1.0-beta-7.jar
maven-model-builder-3.0.3.jar           wagon-provider-api-1.0-beta-7.jar
maven-plugin-api-3.0.3.jar              xercesMinimal-1.9.6.2.jar
maven-repository-metadata-3.0.3.jar
}}}

!!!Maven-WAR-Files
Maven-WAR-Files (auch Thin-WAR-Files genannt) werden wie wie folgt aufgebaut:

# Es ist kein <war-file>/WEB-INF/lib enthalten.
# In <war-file>/META-INF/context.xml befindet sich die Datei [context.xml].
# In <war-file>/META-INF/pom.xml befindet sich die POM-Datei mit dem das WAR-File gebaut worden ist.

Beim Deployment wird dadurch der [Maven Loader] aktiviert, der dann die POM-Datei des Projekts öffnet und die Dependencies zum Class-Path hinzufügt. Falls die Dependencies nicht im lokalen Repository sind, werden diese über das Aether-System von Maven heruntergeladen und lokal installiert.

__Hinweis:__ In der erweiterten Tomcat-Instanz können weiterhin full blown WAR-Files installiert werden.

!!Build-Prozess
Hier wird in Kürze eine Maven-Build-Konfiguration stehen, mit der man automatisch die Thin-WARs bauen kann.

!!!Settings
Für den Betrieb von [Maven Loader] ist keine Installation von [Maven] erforderlich, da diese embedded mitgeliefert wird. Es gibt zwei Möglichkeiten, Maven-Settings zu übergeben:

* __Maven-Installation:__ Wenn die Maven-Installation durch die Umgebungsvariable M2_HOME gesetzt ist, werden die ${M2_HOME}/conf/settings.xml verwendet.
* __Unabhängige Settings:__ Es können Settings für Maven von ${CATALINA_HOME}/conf/settings.xml geladen werden. Diese haben Priorität über die Maven-Installation.

!!Repository
Durch die Settings kann das Repository eingestellt werden, in dem die heruntergeladenen Artifakte abgelegt werden. Es kann auch ein eigenes Repository für die Tomcat-Installation verwendet werden:

{{{
<settings>
    ...
    <localRepository>${CATALINA_HOME}/repository</localRepository>
    ...
</settings>
}}}