Kann ich Jars zum Maven 2 Build-Klassenpfad hinzufügen, ohne sie zu installieren?

Question

Maven 2 treibt mich in der Experimentierphase / Quick and Dirty Mock-up Phase der Entwicklung in den Wahnsinn.

Ich habe eine pom.xml Datei, die die Abhängigkeiten für das Web-App-Framework definiert, das ich verwenden möchte, und ich kann aus dieser Datei schnell Starterprojekte erstellen. Manchmal möchte ich jedoch auf eine Bibliothek eines Drittanbieters verweisen, für die es noch keine pom.xml Datei definiert, so dass anstelle der Erstellung der pom.xml Datei für die 3rd-Party-Lib von Hand und installieren Sie sie, und fügen Sie die Abhängigkeit zu meinem pom.xml Ich möchte Maven einfach sagen: "Zusätzlich zu meinen definierten Abhängigkeiten, schließe alle Jars ein, die sich in /lib auch".

Das sollte eigentlich ganz einfach sein, aber wenn es so ist, habe ich etwas übersehen.

Für Hinweise, wie dies zu bewerkstelligen ist, bin ich sehr dankbar. Kurz gesagt, wenn es einen einfachen Weg gibt, Maven auf eine /lib Verzeichnis und erstellen Sie einfach eine pom.xml mit allen beiliegenden Jars, die einer einzigen Abhängigkeit zugeordnet sind, die ich dann auf einen Schlag benennen / installieren und verlinken kann, würde ebenfalls ausreichen.

Answer 1

Probleme der gängigen Ansätze

Die meisten Antworten, die Sie im Internet finden, schlagen vor, entweder die Abhängigkeit in Ihrem lokalen Repository zu installieren oder einen "System"-Bereich in der pom und verteilen Sie die Abhängigkeit mit dem Quellcode Ihres Projekts. Aber beide Lösungen sind eigentlich fehlerhaft.

Warum Sie den "Install to Local Repo"-Ansatz nicht anwenden sollten

Wenn Sie eine Abhängigkeit in Ihrem lokalen Repository installieren, verbleibt sie dort. Ihr Distributions-Artefakt funktioniert einwandfrei, solange es Zugriff auf dieses Repository hat. Das Problem ist, dass sich dieses Repository in den meisten Fällen auf Ihrem lokalen Rechner befindet, so dass es keine Möglichkeit gibt, diese Abhängigkeit auf einem anderen Rechner aufzulösen. Ihr Artefakt von einem bestimmten Rechner abhängig zu machen, ist eindeutig kein guter Weg, die Dinge zu handhaben. Andernfalls muss diese Abhängigkeit auf jedem Rechner, der mit dem Projekt arbeitet, lokal installiert werden, was auch nicht besser ist.

Warum Sie den Ansatz des "Systemumfangs" nicht anwenden sollten

Die Jars, von denen Sie mit dem "System Scope"-Ansatz abhängig sind, werden weder in einem Repository installiert noch an Ihre Zielpakete angehängt. Deshalb wird Ihr Distributionspaket keine Möglichkeit haben, diese Abhängigkeit aufzulösen, wenn es verwendet wird. Ich glaube, das war der Grund, warum die Verwendung von System Scope sogar veraltet ist. Wie auch immer, Sie wollen sich nicht auf ein veraltetes Feature verlassen.

Die statische projektinterne Repository-Lösung

Nachdem Sie dies in Ihrem pom :

<repository>
    <id>repo</id>
    <releases>
        <enabled>true</enabled>
        <checksumPolicy>ignore</checksumPolicy>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
    <url>file://${project.basedir}/repo</url>
</repository>

für jedes Artefakt mit einer Gruppenkennung der Form x.y.z Maven wird bei der Suche nach Artefakten den folgenden Ort in Ihrem Projektverzeichnis berücksichtigen:

repo/
| - x/
|   | - y/
|   |   | - z/
|   |   |   | - ${artifactId}/
|   |   |   |   | - ${version}/
|   |   |   |   |   | - ${artifactId}-${version}.jar

Weitere Informationen hierzu finden Sie unter dieser Blogbeitrag .

Verwenden Sie Maven zur Installation im Projektarchiv

Anstatt diese Struktur von Hand zu erstellen, empfehle ich die Verwendung eines Maven-Plugins, um Ihre Jars als Artefakte zu installieren. Um also ein Artefakt in ein projektinternes Repository zu installieren unter repo Ordner ausführen:

mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -Dfile=[your-jar] -DgroupId=[...] -DartifactId=[...] -Dversion=[...]

Wenn Sie diesen Ansatz wählen, können Sie die Repository-Deklaration in pom zu:

<repository>
    <id>repo</id>
    <url>file://${project.basedir}/repo</url>
</repository>

Ein Hilfsskript

Da die Ausführung des Installationsbefehls für jede Bibliothek ziemlich lästig und definitiv fehleranfällig ist, habe ich ein Hilfsskript die automatisch alle Jars aus einer lib Ordner zu einem Projekt-Repository, wobei alle Metadaten (groupId, artifactId usw.) automatisch aus den Namen der Dateien aufgelöst werden. Das Skript gibt auch die Abhängigkeits-XML aus, die Sie per Copy-Paste in Ihr pom .

Nehmen Sie die Abhängigkeiten in Ihr Zielpaket auf

Wenn Sie Ihr projektinternes Repository erstellt haben, haben Sie das Problem der Verteilung der Abhängigkeiten des Projekts mit seinem Quellcode gelöst, aber seitdem hängt das Zielartefakt Ihres Projekts von nicht veröffentlichten Jars ab, so dass es bei der Installation in ein Repository unauflösbare Abhängigkeiten haben wird.

Um dieses Problem zu umgehen, schlage ich vor, diese Abhängigkeiten in Ihr Zielpaket aufzunehmen. Dies können Sie entweder mit dem Montage-Plugin oder besser mit dem OneJar-Plugin . Die offizielle Dokumentation zu OneJar ist leicht verständlich.

Answer 2

Nur für Wegwerfcodes

scope == system setzen und einfach eine groupId, artifactId und version erstellen

<dependency>
    <groupId>org.swinglabs</groupId>
    <artifactId>swingx</artifactId>
    <version>0.9.2</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/swingx-0.9.3.jar</systemPath>
</dependency>

Hinweis: Systemabhängigkeiten werden nicht in das Ergebnis jar/war kopiert.
(siehe Einbindung von Systemabhängigkeiten in ein mit Maven erstelltes War )

Answer 3

Sie können ein lokales Repository für Ihr Projekt erstellen

Wenn Sie zum Beispiel Folgendes haben libs Ordner in der Projektstruktur

• En libs Ordner sollten Sie eine Verzeichnisstruktur wie folgt erstellen: /groupId/artifactId/version/artifactId-version.jar

• In Ihrer pom.xml sollten Sie das Repository registrieren

   <repository>
       <id>ProjectRepo</id>
       <name>ProjectRepo</name>
       <url>file://${project.basedir}/libs</url>
   </repository>

• und fügen Sie die Abhängigkeit wie üblich hinzu

   <dependency>
       <groupId>groupId</groupId>
       <artifactId>artifactId</artifactId>
       <version>version</version>
   </dependency>

Das ist alles.

Für weitere Informationen: Wie man externe Bibliotheken in Maven hinzufügt (archiviert)

Answer 4

Hinweis: Bei Verwendung des Systembereichs ( wie auf dieser Seite erwähnt ), benötigt Maven absolute Pfade.

Wenn Ihre Jars unter dem Root Ihres Projekts liegen, sollten Sie Ihren systemPath-Werten ${basedir} voranstellen.

Answer 5

So habe ich es gemacht, es umgeht auch das Paketproblem und funktioniert mit ausgechecktem Code.

Ich habe einen neuen Ordner in dem Projekt erstellt, in meinem Fall habe ich repo aber Sie können auch src/repo

In meinem POM hatte ich eine Abhängigkeit, die in keinem der öffentlichen Maven-Repositories enthalten ist

<dependency>
    <groupId>com.dovetail</groupId>
    <artifactId>zoslog4j</artifactId>
    <version>1.0.1</version>
    <scope>runtime</scope>
</dependency>

Ich habe dann die folgenden Verzeichnisse erstellt repo/com/dovetail/zoslog4j/1.0.1 und kopierten die JAR-Datei in diesen Ordner.

Ich habe die folgende POM-Datei erstellt, um die heruntergeladene Datei darzustellen (dieser Schritt ist optional, aber er beseitigt eine WARNUNG) und hilft dem Nächsten, herauszufinden, woher ich die Datei bekommen habe, um damit zu beginnen.

<?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/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.dovetail</groupId>
    <artifactId>zoslog4j</artifactId>
    <packaging>jar</packaging>
    <version>1.0.1</version>
    <name>z/OS Log4J Appenders</name>
    <url>http://dovetail.com/downloads/misc/index.html</url>
    <description>Apache Log4j Appender for z/OS Logstreams, files, etc.</description>
</project>

Zwei optionale Dateien, die ich erstelle, sind die SHA1-Prüfsummen für das POM und das JAR, um die Warnungen vor fehlenden Prüfsummen zu entfernen.

shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar \
          > repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar.sha1

shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom \
          > repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom.sha1

Schließlich füge ich das folgende Fragment zu meiner pom.xml hinzu, das es mir ermöglicht, auf das lokale Repository zu verweisen

<repositories>
    <repository>
        <id>project</id>
        <url>file:///${basedir}/repo</url>
    </repository>
</repositories>