it-swarm.com.de

Kann ich maven 2 build classpath jars hinzufügen, ohne sie zu installieren?

Maven2 macht mich während der Experimentier-/schnellen und schmutzigen Mock-up-Phase der Entwicklung verrückt.

Ich habe eine pom.xml -Datei, die die Abhängigkeiten für das Web-App-Framework definiert, das ich verwenden möchte, und aus dieser Datei kann ich schnell Startprojekte generieren. Manchmal möchte ich jedoch eine Verknüpfung zu einer Drittanbieter-Bibliothek herstellen, für die noch keine pom.xml -Datei definiert ist, anstatt die pom.xml -Datei für die Drittanbieter-Bibliothek manuell zu erstellen und zu installieren füge die Abhängigkeit zu meinem pom.xml hinzu, ich möchte Maven nur sagen: "Zusätzlich zu meinen definierten Abhängigkeiten füge alle Gläser hinzu, die sich in /lib befinden."

Es scheint, dass dies einfach sein sollte, aber wenn es so ist, vermisse ich etwas.

Hinweise dazu sind sehr willkommen. Kurz gesagt, wenn es eine einfache Möglichkeit gibt, maven auf ein /lib -Verzeichnis zu verweisen und einfach ein pom.xml mit allen beigefügten Gläsern zu erstellen, die einer einzelnen Abhängigkeit zugeordnet sind, die ich dann benennen/installieren und verknüpfen könnte auf einen Schlag würde auch genügen.

681
purple

Probleme der gängigen Ansätze

Die meisten Antworten, die Sie im Internet finden, schlagen vor, dass Sie entweder die Abhängigkeit in Ihrem lokalen Repository installieren oder einen "System" -Bereich in pom angeben und die Abhängigkeit mit der Quelle Ihres Projekts verteilen. Diese beiden Lösungen sind jedoch tatsächlich fehlerhaft.

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

Wenn Sie eine Abhängigkeit zu Ihrem lokalen Repository installieren, bleibt sie dort. Ihr Distributionsartefakt funktioniert einwandfrei, solange es Zugriff auf dieses Repository hat. Das Problem besteht in den meisten Fällen darin, dass sich dieses Repository auf Ihrem lokalen Computer befindet, sodass es keine Möglichkeit gibt, diese Abhängigkeit von einem anderen Computer zu beheben. Es ist keine Möglichkeit, Ihr Artefakt von einer bestimmten Maschine abhängig zu machen. Andernfalls muss diese Abhängigkeit lokal auf jedem Computer installiert werden, der mit dem Projekt arbeitet, das nicht besser ist.

Warum sollten Sie den "System Scope" -Ansatz nicht anwenden?

Die Jars, auf die Sie beim "System Scope" -Ansatz angewiesen sind, werden weder in einem Repository installiert noch an Ihre Zielpakete angehängt. Aus diesem Grund kann Ihr Distributionspaket diese Abhängigkeit bei Verwendung nicht auflösen. Das war meines Erachtens der Grund, warum die Verwendung des Systemumfangs sogar veraltet war. Auf keinen Fall möchten Sie sich auf eine veraltete Funktion verlassen.

Die statische Projektarchivlösung

Nachdem Sie dies in Ihr pom eingegeben haben:

<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 Gruppen-ID der Form x.y.z nimmt Maven bei der Suche nach Artefakten die folgende Position in Ihr Projektverzeichnis auf:

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

Um mehr darüber zu erfahren, lesen Sie diesen Blog-Beitrag .

Verwenden Sie Maven zum Installieren, um Repo zu projizieren

Anstatt diese Struktur von Hand zu erstellen, empfehle ich, ein Maven-Plugin zu verwenden, um Ihre Gläser als Artefakte zu installieren. Um ein Artefakt in einem projektinternen Repository unter dem Ordner repo zu installieren, führen Sie Folgendes aus:

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 vereinfachen, um:

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

Ein Hilfsskript

Da das Ausführen des Installationsbefehls für jede Bibliothek etwas ärgerlich und definitiv fehleranfällig ist, habe ich ein Dienstprogramm-Skript erstellt, das automatisch alle Gläser aus einem lib -Ordner in ein Projekt-Repository installiert Auflösen aller Metadaten (Gruppen-ID, Artefakt-ID usw.) aus Dateinamen. Das Skript druckt auch das Abhängigkeits-XML aus, damit Sie es in Ihr pom kopieren und einfügen können.

Fügen Sie die Abhängigkeiten in Ihr Zielpaket ein

Wenn Sie Ihr projektinternes Repository erstellt haben, haben Sie ein Problem beim Verteilen der Abhängigkeiten des Projekts mit der Quelle behoben, aber seitdem hängt das Zielartefakt Ihres Projekts von nicht veröffentlichten Gläsern ab es zu einem Repository wird es unlösbare Abhängigkeiten haben.

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

581
Nikita Volkov

Nur zum Wegwerfen von Code

setze scope == system und erstelle eine groupId, artifactId und version

<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 resultierende Jar/War kopiert
(siehe Einbeziehen von Systemabhängigkeiten in mit maven erstellte Kriege )

470
Pyrolistical

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

Zum Beispiel, wenn Sie den Ordner libs in der Projektstruktur haben

  • Im Ordner libs 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 gewohnt hinzu

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

Das ist alles.

Für detaillierte Informationen: Wie man externe Bibliotheken in Maven hinzufügt

56

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

Wenn sich Ihre Jars unter dem Stammverzeichnis Ihres Projekts befinden, möchten Sie Ihren systemPath-Werten $ {basedir} voranstellen.

30
Ed Brannin

Dies ist, was ich getan habe, es funktioniert auch um das Paket Problem und es funktioniert mit ausgecheckten Code.

Ich habe im Projekt einen neuen Ordner erstellt, in dem ich repo verwendet habe, kann aber auch src/repo verwenden.

In meinem POM hatte ich eine Abhängigkeit, die sich in keinem öffentlichen Maven-Repository befindet

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

Ich erstellte dann die folgenden Verzeichnisse repo/com/dovetail/zoslog4j/1.0.1 und kopierte die JAR-Datei in diesen Ordner.

Ich habe die folgende POM-Datei erstellt, um die heruntergeladene Datei darzustellen (dieser Schritt ist optional, entfernt jedoch eine WARNUNG) und hilft dem nächsten Benutzer herauszufinden, woher die Datei stammt.

<?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 den POM und die JAR, um die fehlenden Prüfsummenwarnungen 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, mit dem ich auf das lokale Repository verweisen kann

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

Sie sollten wirklich ein Framework über ein Repository einrichten und Ihre Abhängigkeiten im Voraus identifizieren. Die Verwendung des Systembereichs ist ein häufiger Fehler, den Benutzer verwenden, weil ihnen "das Abhängigkeitsmanagement egal ist". Das Problem dabei ist, dass Sie am Ende einen perversen Maven-Build haben, der Maven in einem normalen Zustand nicht anzeigt. Bei einem Ansatz wie this ist es besser für Sie.

13
Brian Fox

Maven-Installations-Plugin hat die Befehlszeilenverwendung zum Installieren einer JAR in das lokale Repository. POM ist optional, Sie müssen jedoch die GroupId, ArtifactId, Version und Verpackung (alles POM-Zeug) angeben.

12
toad

So fügen wir ein lokales Glas hinzu oder installieren es

    <dependency>
        <groupId>org.example</groupId>
        <artifactId>iamajar</artifactId>
        <version>1.0</version>
        <scope>system</scope>
        <systemPath>${project.basedir}/lib/iamajar.jar</systemPath>
    </dependency>

ich habe einige Standard-Gruppen-ID und -Artefakt-ID angegeben, weil sie obligatorisch sind :)

10

Ich habe einen anderen Weg gefunden, siehe hier von einem Heroku-Post

Zusammenfassend (Entschuldigung für das Kopieren und Einfügen)

  • Erstellen Sie ein repo -Verzeichnis in Ihrem Stammordner:
 Ihr Projekt 
 + - pom.xml 
 + - src 
 + - repo 
  • Führen Sie dies aus, um die JAR in Ihrem lokalen Repo-Verzeichnis zu installieren
 mvn deploy: deploy-file -Durl = file: /// path/to/yourproject/repo/-Dfile = mylib-1.0.jar -DgroupId = com.example -DartifactId = mylib -Dpackaging = jar - Dversion = 1,0 
  • Füge dies als pom.xml hinzu:
<repositories>
    <!--other repositories if any-->
    <repository>
        <id>project.local</id>
        <name>project</name>
        <url>file:${project.basedir}/repo</url>
    </repository>
</repositories>


<dependency>
    <groupId>com.example</groupId>
    <artifactId>mylib</artifactId>
    <version>1.0</version>  
</dependency>
8
xbeta

Die Verwendung von <scope>system</scope> ist aus von anderen erklärten Gründen eine schreckliche Idee. Wenn Sie die Datei manuell in Ihr lokales Repository installieren, kann der Build nicht reproduziert werden, und die Verwendung von <url>file://${project.basedir}/repo</url> ist ebenfalls keine gute Idee, da (1) dies möglicherweise nicht der Fall ist eine wohlgeformte file URL (z. B. wenn das Projekt in einem Verzeichnis mit ungewöhnlichen Zeichen ausgecheckt ist), (2) ist das Ergebnis unbrauchbar, wenn der POM dieses Projekts als Abhängigkeit des Projekts eines anderen Benutzers verwendet wird.

Angenommen, Sie möchten das Artefakt nicht in ein öffentliches Repository hochladen, ist der Vorschlag von Simeon, ein Hilfsmodul zu verwenden, ausreichend. Aber es gibt jetzt einen einfacheren Weg ...

Die Empfehlung

Verwenden Sie non-maven-jar-maven-plugin . Tut genau das, wonach Sie gefragt haben, ohne die Nachteile der anderen Ansätze.

8
Jesse Glick

Nach einer langen Diskussion mit den CloudBees-Mitarbeitern über die ordnungsgemäße Verpackung solcher JARs legten sie einen interessanten guten Lösungsvorschlag vor:

Erstellung eines gefälschten Maven-Projekts, das eine bereits vorhandene JAR als primäres Artefakt anfügt und auf die Ausführung der dazugehörigen POM-Installation (Installationsdatei) stößt. Hier ist ein Beispiel für eine solche Kinf von POM:

 <build>
    <plugins>
        <plugin>
            <groupId>org.Apache.maven.plugins</groupId>
            <artifactId>maven-install-plugin</artifactId>
            <version>2.3.1</version>
            <executions>
                <execution>
                    <id>image-util-id</id>
                    <phase>install</phase>
                    <goals>
                        <goal>install-file</goal>
                    </goals>
                    <configuration>
                        <file>${basedir}/file-you-want-to-include.jar</file>
                        <groupId>${project.groupId}</groupId>
                        <artifactId>${project.artifactId}</artifactId>
                        <version>${project.version}</version>
                        <packaging>jar</packaging>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Zur Umsetzung sollte jedoch die bestehende Projektstruktur geändert werden. Zunächst sollten Sie bedenken, dass für jede Art von JAR ein anderes Fake-Maven-Projekt (Modul) erstellt werden sollte. Außerdem sollte ein übergeordnetes Maven-Projekt erstellt werden, das alle Untermodule enthält: alle JAR-Wrapper und das vorhandene Hauptprojekt. Die Struktur könnte sein:

root-Projekt (enthält die übergeordnete POM-Datei, die alle Submodule mit enthält modul XML-Element) (POM-Paketierung)

JAR 1 Wrapper Maven-Unterprojekt (POM-Verpackung)

JAR 2-Wrapper Maven-Unterprojekt (POM-Verpackung)

hauptprojekt für Maven-Kinder (WAR, JAR, EAR .... Verpackung)

Wenn das übergeordnete Element über mvn: install oder mvn: packaging ausgeführt wird, werden Submodule ausgeführt. Das könnte hier ein Minus sein, da die Projektstruktur geändert werden sollte, aber am Ende eine nicht statische Lösung bietet

6
Simeon Angelov

Das Problem mit systemPath ist, dass die Gläser der Abhängigkeiten nicht als transitiven Abhängigkeiten entlang Ihrer Artefakte verteilt werden. Versuchen Sie, was ich hier gepostet habe: Ist es am besten, die JAR-Dateien Ihres Projekts zu mavenisieren oder sie in WEB-INF/lib abzulegen?

Dann deklarieren Sie wie gewohnt Abhängigkeiten.

Und bitte lesen Sie die Fußzeile.

4
mschonaker

Wenn Sie eine schnelle und schmutzige Lösung suchen, können Sie Folgendes tun (obwohl ich dies nur für Testprojekte empfehle, wird sich maven ausführlich darüber beschweren, dass dies nicht richtig ist).

Fügen Sie für jede benötigte JAR-Datei einen Abhängigkeitseintrag hinzu, vorzugsweise mit einem Perl-Skript oder ähnlichem, und kopieren Sie diesen in Ihre POM-Datei.

#! /usr/bin/Perl

foreach my $n (@ARGV) {

    [email protected]*/@@;

    print "<dependency>
    <groupId>local.dummy</groupId>
    <artifactId>$n</artifactId>
    <version>0.0.1</version>
    <scope>system</scope>
    <systemPath>\${project.basedir}/lib/$n</systemPath>
</dependency>
";
3
Alex Lehmann

Eine schnelle & schmutzige Batch-Lösung (basierend auf Alex 'Antwort):

libs.bat

@ECHO OFF
FOR %%I IN (*.jar) DO (
echo ^<dependency^>
echo ^<groupId^>local.dummy^</groupId^>
echo ^<artifactId^>%%I^</artifactId^>
echo ^<version^>0.0.1^</version^>
echo ^<scope^>system^</scope^>
echo ^<systemPath^>${project.basedir}/lib/%%I^</systemPath^>
echo ^</dependency^>
)

Führen Sie es so aus: libs.bat > libs.txt. Öffnen Sie dann libs.txt und kopieren Sie den Inhalt als Abhängigkeiten.

In meinem Fall brauchte ich nur die Bibliotheken, um meinen Code zu kompilieren, und diese Lösung war die beste für diesen Zweck.

3
lmiguelmh

Am einfachsten erscheint mir, wenn Sie Ihr Maven-Compiler-Plugin so konfigurieren, dass es Ihre benutzerdefinierten Gläser enthält. In diesem Beispiel werden alle JAR-Dateien in ein lib-Verzeichnis geladen.

        <plugin>
            <groupId>org.Apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <includes>
                    <include>lib/*.jar</include>
                </includes>
            </configuration>
        </plugin>
3
realgt

Verwenden Sie das maven-install-plugin, um die Drittanbieter-JAR-Datei zu installieren, die sich nicht im Maven-Repository befindet.

Unten sind Schritte:

  1. Laden Sie die JAR-Datei manuell von der Quelle (Website) herunter
  2. Erstellen Sie einen Ordner und legen Sie Ihre JAR-Datei darin ab
  3. Führen Sie den folgenden Befehl aus, um das Drittanbieter-JAR in Ihrem lokalen Maven-Repository zu installieren

mvn install: install-file -Dfile = -DgroupId = -DartifactId = -Dversion = -Dpackaging =

Unten ist das Beispiel, das ich für simonsite log4j verwendet habe

mvn install: install-file -Dfile =/Users/athanka/git/MyProject/repo/log4j-rolling-appender.jar -DgroupId = de.org.simonsite -DartifactId = log4j-rolling-appender -Dversion = 20150607-2059 - Dpackaging = Glas

  1. In der pom.xml ist die Abhängigkeit wie folgt einzuschließen

      <dependency> 
            <groupId>uk.org.simonsite</groupId>
            <artifactId>log4j-rolling-appender</artifactId>
            <version>20150607-2059</version> 
      </dependency>
    
  2. Führen Sie den Befehl mvn clean install aus, um Ihre Verpackung zu erstellen

Unten ist der Referenzlink:

https://maven.Apache.org/guides/mini/guide-3rd-party-jars-local.html

2
Andrew TR

Eine seltsame Lösung fand ich:

mit Eclipse

  • erstellen Sie ein einfaches Java -Projekt (ohne Benutzerkonto)
  • füge eine Hauptklasse hinzu
  • füge alle Gläser dem Klassenpfad hinzu
  • exportiere Runnable JAR (es ist wichtig, weil es hier keinen anderen Weg gibt)
  • wählen Sie Erforderliche Bibliotheken in generierte JAR extrahieren
  • entscheide über die Lizenzprobleme
  • tadammm ... installiere das generierte Glas auf deinem m2repo
  • fügen Sie diese einzelne Abhängigkeit zu Ihren anderen Projekten hinzu.

prost, Balint

2
Balint Pato

Für diejenigen, die hier keine gute Antwort gefunden haben, ist dies das, was wir tun, um ein Glas mit allen notwendigen Abhängigkeiten zu bekommen. In dieser Antwort ( https://stackoverflow.com/a/7623805/1084306 ) wird die Verwendung des Maven Assembly-Plug-ins erwähnt, die Antwort enthält jedoch kein Beispiel. Und wenn Sie die Antwort nicht bis zum Ende lesen (sie ist ziemlich langwierig), werden Sie sie möglicherweise verpassen. Wenn Sie das Folgende zu Ihrer pom.xml hinzufügen, wird target/${PROJECT_NAME}-${VERSION}-jar-with-dependencies.jar generiert.

        <plugin>
            <groupId>org.Apache.maven.plugins</groupId>
            <artifactId>maven-Assembly-plugin</artifactId>
            <version>2.4.1</version>
            <configuration>
                <!-- get all project dependencies -->
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
                <!-- MainClass in mainfest make a executable jar -->
                <archive>
                  <manifest>
                    <mainClass>my.package.mainclass</mainClass>
                  </manifest>
                </archive>

            </configuration>
            <executions>
              <execution>
                <id>make-Assembly</id>
                <!-- bind to the packaging phase -->
                <phase>package</phase> 
                <goals>
                    <goal>single</goal>
                </goals>
              </execution>
            </executions>
        </plugin>
2
Donovan

Auch wenn es nicht genau zu Ihrem Problem passt, werde ich dies hier fallen lassen. Meine Anforderungen waren:

  1. Gläser, die nicht in einem Online-Maven-Repository gefunden werden können, sollten sich im SVN befinden.
  2. Wenn ein Entwickler eine weitere Bibliothek hinzufügt, sollten sich die anderen Entwickler nicht mit der manuellen Installation dieser Bibliotheken befassen.
  3. Das IDE (in meinem Fall NetBeans) sollte in der Lage sein, die Quellen und Javadocs zu finden, um Autovervollständigung und Hilfe bereitzustellen.

Lassen Sie uns zuerst über (3) sprechen: Nur die Gläser in einem Ordner zu haben und sie irgendwie in das endgültige Glas zu mischen, wird hier nicht funktionieren, da das IDE dies nicht versteht. Dies bedeutet, dass alle Bibliotheken ordnungsgemäß installiert werden müssen. Ich möchte jedoch nicht, dass jeder es mit "mvn install-file" installiert.

In meinem Projekt brauchte ich Metawidget. Auf geht's:

  1. Erstellen Sie ein neues Maven-Projekt (nennen Sie es "shared-libs" oder so ähnlich).
  2. Laden Sie metawidget herunter und extrahieren Sie die Zip-Datei in src/main/lib.
  3. Der Ordner doc/api enthält die Javadocs. Erstellen Sie eine Zip-Datei des Inhalts (doc/api/api.Zip).
  4. Ändern Sie den pom wie folgt
  5. Erstellen Sie das Projekt und die Bibliothek wird installiert.
  6. Fügen Sie die Bibliothek als Abhängigkeit zu Ihrem Projekt hinzu oder fügen Sie (wenn Sie die Abhängigkeit im Projekt shared-libs hinzugefügt haben) shared-libs als Abhängigkeit hinzu, um alle Bibliotheken gleichzeitig abzurufen.

Jedes Mal, wenn Sie eine neue Bibliothek haben, fügen Sie einfach eine neue Ausführung hinzu und weisen Sie alle an, das Projekt erneut zu erstellen (Sie können diesen Prozess mit Projekthierarchien verbessern).

2
Cephalopod

Dies beantwortet nicht die Frage, wie Sie sie zu Ihrem POM hinzufügen sollen, und ist möglicherweise ein Kinderspiel, würde aber einfach das Bibliotheksverzeichnis zu Ihrer Klassenpfadarbeit hinzufügen? Ich weiß, dass ich das tue, wenn ich ein externes Gefäß brauche, das ich nicht zu meinen Maven-Repos hinzufügen möchte.

Hoffe das hilft.

0
javamonkey79

Ich habe in einem Kommentar zu der Antwort von @alex lehmann's auf einen python Code angespielt, also poste ich ihn hier.

def AddJars(jarList):
  s1 = ''
  for elem in jarList:
   s1+= """
     <dependency>
        <groupId>local.dummy</groupId>
        <artifactId>%s</artifactId>
        <version>0.0.1</version>
        <scope>system</scope>
        <systemPath>${project.basedir}/manual_jars/%s</systemPath>
     </dependency>\n"""%(elem, elem)
  return s1
0
Paul

Was in unserem Projekt funktioniert, ist das, was Archimedes Trajano geschrieben hat, aber wir hatten in unserer .m2/settings.xml etwas in der Art:

 <mirror>
  <id>nexus</id>
  <mirrorOf>*</mirrorOf>
  <url>http://url_to_our_repository</url>
 </mirror>

und das * sollte auf zentral geändert werden. Wenn seine Antwort für Sie nicht funktioniert, sollten Sie Ihre settings.xml überprüfen

0
Łukasz Klich