Migrieren Sie Ihr Projekt zu maven 2 - TEIL III

Maven 2.0.4 ist nun schon seit einiger Zeit verfügbar, also habe ich mich entschlossen, es noch einmal zu versuchen, nachdem ich erfolglos versucht hatte, zu Maven 2 zu migrieren (mit Maven 2.0.3). Ich versuche, ein WAR-Projekt zu migrieren. Es hat mehrere Abhängigkeiten zu einigen Artefakten, die vom Maven-Repository bereitgestellt werden, aber auch zu solchen, die es nicht sind (z.B. sjsxp für Streaming Parsing). Ich werde versuchen, die War-Anwendung mit Maven 2 zu erstellen und bereitzustellen. Und wissen Sie was? Diesmal hat es geklappt!

Fangen wir dort an, wo ich beim letzten Mal stecken geblieben bin: bei der Sache mit den Berichten. Wie sich herausstellt, funktionieren alle Berichte, die wir haben, jetzt in Maven 2.0.4! Okay, nicht ganz out-of-the-box, aber es funktioniert! Wir haben die folgenden Berichte in unserem Projekt:

1. Checkstyle
2. javadoc
3. jxr (pmd)
4. surefire (Einheitstest)
5. Klee
6. pmd
7. jdepend
8. findbugs
9. Affen

Die letzten drei Berichte sind nur in SNAPSHOT-Versionen von codehaus.org verfügbar. Um sicherzustellen, dass Sie SNAPSHOT-Versionen verwenden können, müssen Sie Folgendes zu Ihrer pom.xml hinzufügen

   
  Maven Schnappschüsse
 
https://snapshots.maven.codehaus.org/maven2/

  true

  false

Dem findbugs-Plugin fehlt die Abhängigkeit zu jaxen. Die folgende Abhängigkeit muss in der pom.xml der (MAVEN_REPO/findbugs/core-plugin/0.9.3/pom.xml) hinzugefügt werden.

    
  jaxen
  jaxen
  1.1-beta-7

Ich habe versucht, es in meiner eigenen pom.xml hinzuzufügen, aber das hat nicht funktioniert. Der Unterschied zwischen der Konfiguration von Plugins für Maven 2 im Gegensatz zu Maven 1.x besteht darin, dass jetzt die gesamte Konfiguration in der pom.xml (oder der settings.xml) enthalten ist. In Maven 1.x mussten Sie zum Beispiel den Speicherort der Lizenzdatei für das Clover-Plugin in der project.properties wie folgt definieren: maven.clover.license.path=${maven.repo.local}/clover/licenses/clover-xebia.license Und die Ausführung von Clover konnte in der maven.xml als Pre-Target wie folgt definiert werden:

Wie Sie wissen, gibt es die project.properties und maven.xml nicht mehr, daher wird dies in der pom.xml wie folgt definiert:

  org.apache.maven.plugins
  maven-clover-plugin

  ${path}/clover-xebia.license

  Vor der Website

  Instrument

Beachten Sie, dass es ein <configuration> Tag gibt, in dem Sie die notwendige Konfiguration für das von Ihnen verwendete Plugin definieren können. Weitere Informationen finden Sie in der Dokumentation des Plugins, siehe maven.apache.org/plugins/ oder mojo.codehaus.org/. Das Tag <executions> enthält Informationen darüber, wann dieses Plugin ausgeführt werden soll. Jede Ausführung definiert ihre Phasen, wann sie ausgeführt werden soll und die Ziele, die sie ausführen muss. Weitere Informationen über Phasen finden Sie unter Einführung in den Lebenszyklus. Die obige Konfiguration stellt sicher, dass clover alle Quellen instrumentiert (mit clover kompiliert) und eine neue clover Datenbank erstellt. In unseren Projekten gibt es auch Abhängigkeiten, die nicht über das Maven Repository verfügbar sind, wie z.B. sjsxp-1.0.jar. Wir haben ein internes Repository für diese Art von Jars. Um Jars zu installieren und die pom.xml für diese Art von Jars zu generieren, können Sie wie folgt vorgehen (dank dieses exzellenten Blogs): Vergewissern Sie sich, dass Sie einen privaten und einen öffentlichen Schlüssel generiert haben und so etwas wie Pageant laufen haben. Dann fügen Sie das folgende Fragment in Ihre settings.xml-Datei ein:

...

  ...

  ssh-xebia-repo
  Benutzername
 
/path/to/ppkfile/file.ppk

 
/path/to/plink.exe
 
/path/to/pscp.exe

Ich habe dafür putty tools verwendet und es hat gut funktioniert (nachdem Maarten mir geholfen hat). Führen Sie dann den folgenden Befehl in der Befehlszeile aus (beachten Sie, dass der Wert des Attributs [xml][/xml] und der -DrepositoryId derselbe sind): mvn deploy:deploy-file -DgroupId=sjsxp -DartifactId=sjsxp -Dversion=1.0 -Durl=scpexe://url/path/to/repo -DrepositoryId=ssh-xebia-repo -DpomFile=pom.xml -Dfile=sjsxp-1.0.jar Um nun Artefakte aus Ihrem internen Repository herunterzuladen, können Sie Ihr Repository in Ihrer pom.xml wie folgt definieren:

...

  xebia-repo
  Internes Xebia-Repository
 
https://url.repo.com/

Wenn Sie die Authentifizierung aktiviert haben, müssen Sie Ihren Benutzernamen und Ihr Passwort in der settings.xml wie folgt definieren (beachten Sie, dass der Wert des Attributs <id> derselbe ist):

...

  xebia-repo
  Benutzername
  Passwort

Wir können jetzt testen, die Site ausführen und Artefakte in einem entfernten Repository bereitstellen. Lassen Sie uns nun die WAR erstellen. Das ist mit Maven 2 ziemlich einfach. Fügen Sie einfach Folgendes zu Ihrer pom.xml hinzu

....
  Krieg

  ...

  ...

  org.apache.maven.plugins
  maven-war-plugin

  Namen-Krieg
  src/web

Das Attribut <packaging> zeigt an, dass es sich bei dem Artefakt dieses Projekts um eine WAR handelt. Dann können Sie das maven-war-plugin hinzufügen und die Standardkonfiguration anpassen. Führen Sie dann z.B. mvn package aus, und die WAR wird erstellt. Bei der Erstellung der WAR habe ich festgestellt, dass die jta-1.0.1B.jar in der WAR enthalten war. Diese wird normalerweise vom JEE (alias J2EE) Server bereitgestellt, so dass ich sie nicht in meine WAR aufnehmen möchte. Wie sich herausstellte, hat Hibernate es als eine Abhängigkeit mit dem Standardumfang (Kompilieren) deklariert(hier finden Sie weitere Informationen zu Umfang und Abhängigkeiten) und daher ist es in meiner WAR enthalten. Um sie nicht in meiner WAR zu haben, muss ich die Abhängigkeit in meiner pom.xml explizit mit dem Scope "provided" angeben:

   
  javax.transaction
  jta
  1.0.1B
  bereitgestellt

Auf diese Weise ist es während der Kompilierung verfügbar, wird aber nicht in meine WAR eingefügt. Unsere WAR läuft auf einem Weblogic-Server (8.1 SP4) und mit Maven 1.x haben wir sie über die Weblogic-Plugins bereitgestellt. Wie sich herausstellt, ist dieses Plugin auch für Maven 2 verfügbar. Hier sehen Sie, wie Sie es in Ihrer pom.xml definieren:

...

  ...

  org.codehaus.mojo
  weblogic-maven-plugin
  2.8.0-SNAPSHOT

  localhost
  7001
  http
  ${weblogic.userId}
  ${weblogic.password}
  false
  false
  false
  false
  ${weblogic.serverName}

Da die userId und das Passwort von Installation zu Installation unterschiedlich sein können, kann dies in der settings.xml wie folgt externalisiert werden:

           

  weblogicConfig

  weblogic
  weblogic
  dev

  weblogicConfig

Dies gilt für alle Eigenschaften, die Sie externalisieren möchten. Sie müssen ein <Profil> erstellen und es im Abschnitt <activeProfiles> aktivieren, es gibt noch andere Möglichkeiten, es zu aktivieren, aber das ist im Moment nicht relevant. Wenn Sie eine Migration planen, sollten Sie Folgendes beachten:

• Reservieren Sie sich Zeit, um auf Maven 2 zu migrieren. Da es keinen Migrationsleitfaden gibt, außer diesem maven.apache.org/guides/mini/guide-m1-m2.html etwas, das keine große Hilfe ist.
• Abhängigkeiten werden verschoben. In den meisten Fällen wird der Speicherort von Maven 1 noch unterstützt, aber wer weiß, wie lange noch. Wenn eine Abhängigkeit an einen neuen Ort verschoben wird, sehen Sie in Ihrer Konsole Meldungen wie diese: . Wenn Sie diese Meldung sehen, ändern Sie einfach die groupId und artifactId, falls erforderlich, auf den neuen Ort (das Format der Meldung ist: groupId:artifactId:version).
• Die Dateien build.properties und project.properties werden durch settings.xml ersetzt. Es kann schwierig sein, herauszufinden, wo Sie die Eigenschaften, die Sie dort definiert haben, ablegen sollen. Einige gehören in die pom.xml und einige in die settings.xml. Prüfen Sie alle verfügbaren Dokumentationen (googeln Sie) und Sie werden es irgendwann herausfinden.
• Das Gleiche gilt für maven.xml, obwohl ich unser benutzerdefiniertes Distributionsartefakt-Skript (ant) noch nicht von maven.xml migriert habe.
• Meiner Meinung nach mangelt es der Maven-Homepage (noch) an einer klaren Dokumentation, daher benutze ich viel Google.

Nach all dem würde ich sagen, dass es sicher ist, auf Maven 2.0.4 umzusteigen. Es gibt keine vagen Ausnahmen mehr auf Ihrer Konsole und alles scheint zu funktionieren (vielleicht mit ein paar SNAPSHOT-Versionen von Plugins, aber wen interessiert das schon). Referenzen:

• www.coffeebreaks.org/blogs/?p=37, Blog über Maven 2 Repositories.
• maven.apache.org/maven-settings/settings.html, der Deskriptor der Datei settings.xml.
• maven.apache.org/ref/2.0.3-SNAPSHOT/maven-model/maven.html, der Deskriptor der pom.xml.
• maven.apache.org/plugins/, Liste der verfügbaren Plugins.
• mojo.codehaus.org/, eine weitere Liste der verfügbaren Plugins von codehaus.