Maven2 mi sta facendo impazzire durante la fase di sperimentazione / mock-up di sviluppo rapido e sporco.

Ho un pom.xmlfile che definisce le dipendenze per il framework dell'app Web che voglio usare e posso generare rapidamente progetti di avvio da quel file. Tuttavia, a volte voglio collegarmi a una libreria di terze parti che non ha già pom.xmldefinito un file, quindi piuttosto che creare pom.xmlmanualmente il file per la libreria di terze parti e installarlo, e aggiungere la dipendenza al mio pom.xml, vorrei solo per dire a Maven: "Oltre alle mie dipendenze definite, includi anche tutti i vasetti presenti /lib".

Sembra che questo dovrebbe essere semplice, ma se lo è, mi manca qualcosa.

Tutti i suggerimenti su come farlo sono molto apprezzati. A parte questo, se c'è un modo semplice per indicare Maven a una /libdirectory e creare facilmente un pom.xmlcon tutti i barattoli racchiusi mappati su una singola dipendenza che potrei quindi nominare / installare e collegare in un colpo solo sarebbe anche sufficiente.

Problemi di approcci popolari

La maggior parte delle risposte che troverai su Internet ti suggerirà di installare la dipendenza nel tuo repository locale o di specificare un ambito di "sistema" nel pome distribuire la dipendenza con l'origine del tuo progetto. Ma entrambe queste soluzioni sono in realtà imperfette.

Perché non dovresti applicare l'approccio "Installa in Repo locale"

Quando si installa una dipendenza nel proprio repository locale, rimane lì. Il tuo artefatto di distribuzione andrà bene fintanto che avrà accesso a questo repository. Il problema è nella maggior parte dei casi che questo repository risiederà sul tuo computer locale, quindi non ci sarà modo di risolvere questa dipendenza su nessun altro computer. Chiaramente far dipendere il tuo artefatto da una macchina specifica non è un modo per gestire le cose. Altrimenti questa dipendenza dovrà essere installata localmente su ogni macchina che lavora con quel progetto che non è migliore.

Perché non dovresti applicare l'approccio "Ambito del sistema"

I vasi su cui si basa l'approccio "Ambito di sistema" non vengono né installati in alcun repository né collegati ai pacchetti di destinazione. Ecco perché il tuo pacchetto di distribuzione non avrà modo di risolvere tale dipendenza quando utilizzato. Ciò che ritengo fosse il motivo per cui l'uso dell'ambito del sistema è persino diventato obsoleto. Ad ogni modo non vuoi fare affidamento su una funzione obsoleta.

La soluzione di repository statico nel progetto

Dopo aver inserito questo nel tuo 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>

per ogni artefatto con un ID di gruppo in forma x.y.zMaven includerà la seguente posizione all'interno della dir del progetto nella sua ricerca di artefatti:

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

Per approfondire questo, puoi leggere questo post sul blog .

Utilizzare Maven per l'installazione nel project repo

Invece di creare questa struttura a mano, ti consiglio di usare un plugin Maven per installare i tuoi vasetti come artefatti. Quindi, per installare un artefatto in un repository in-project nella repocartella eseguire:

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

Se sceglierai questo approccio, sarai in grado di semplificare la dichiarazione del repository in pom:

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

Una sceneggiatura di aiuto

Poiché l'esecuzione del comando di installazione per ogni libreria è un po 'noiosa e sicuramente soggetta a errori, ho creato uno script di utilità che installa automaticamente tutti i barattoli da una libcartella a un repository di progetto, risolvendo automaticamente tutti i metadati (groupId, artefactId e ecc.) Da nomi dei file. Lo script stampa anche le dipendenze xml che puoi copiare e incollare nel tuo pom.

Includi le dipendenze nel pacchetto di destinazione

Quando avrai creato il tuo repository in-project avrai risolto un problema di distribuzione delle dipendenze del progetto con la sua fonte, ma da allora l'artefatto di destinazione del tuo progetto dipenderà da vasetti non pubblicati, quindi quando installerai in un repository avrà dipendenze irrisolvibili.

Per ovviare a questo problema, suggerisco di includere queste dipendenze nel pacchetto di destinazione. Questo è possibile farlo con il plug-in di assemblaggio o meglio con il plug-in OneJar . Il documentaion ufficiale su OneJar è facile da comprendere.

Solo per il codice di eliminazione

imposta scope == system e crea un groupId, artefactId e versione

<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>

Nota: le dipendenze di sistema non vengono copiate nel jar / war risultante
(vedi Come includere le dipendenze di sistema in war costruite usando maven )

È possibile creare un repository locale sul proprio progetto

Ad esempio se hai una libscartella nella struttura del progetto

• Nella libscartella è necessario creare una struttura di directory come:/groupId/artifactId/version/artifactId-version.jar

• Nel tuo pom.xml dovresti registrare il repository

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

• e aggiungi dipendenza come al solito

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

Questo è tutto.

Per informazioni dettagliate: Come aggiungere librerie esterne in Maven

Nota: quando si utilizza l'ambito del sistema ( come indicato in questa pagina ), Maven necessita di percorsi assoluti.

Se i tuoi vasetti si trovano nella radice del progetto, ti consigliamo di aggiungere un prefisso ai valori di systemPath con $ {basedir}.

Questo è quello che ho fatto, funziona anche con il problema del pacchetto e funziona con il codice estratto.

Nel mio caso ho creato una nuova cartella nel progetto repo, ma mi sento libero di usarlosrc/repo

Nel mio POM avevo una dipendenza che non si trova in nessun deposito pubblico di Mven

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

Ho quindi creato le seguenti directory repo/com/dovetail/zoslog4j/1.0.1e copiato il file JAR in quella cartella.

Ho creato il seguente file POM per rappresentare il file scaricato (questo passaggio è facoltativo, ma rimuove un AVVISO) e aiuta il ragazzo successivo a capire da dove ho preso il file.

<?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>

Due file opzionali che creo sono i checksum SHA1 per POM e JAR per rimuovere gli avvisi di checksum mancanti.

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

Infine aggiungo il seguente frammento al mio pom.xml che mi permette di fare riferimento al repository locale

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

Dovresti davvero creare un framework tramite un repository e identificare le tue dipendenze in anticipo. L'uso dell'ambito del sistema è un errore comune che le persone usano, perché "non si preoccupano della gestione delle dipendenze". Il problema è che in questo modo si finisce con una build pervenuta maven che non mostrerà la maven in condizioni normali. Faresti meglio a seguire un approccio come questo .

Ecco come aggiungere o installare un vaso locale

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

ho dato alcuni ID gruppo e artefatto predefiniti perché sono obbligatori :)

Il plug-in di installazione di Maven ha l'utilizzo della riga di comando per installare un vaso nel repository locale, POM è facoltativo ma dovrai specificare GroupId, ArtifactId, Version e Packaging (tutto il materiale POM).

L'utilizzo <scope>system</scope>è una pessima idea per ragioni spiegate da altri, l'installazione manuale del file nel repository locale rende la build non riproducibile e l'utilizzo <url>file://${project.basedir}/repo</url>non è una buona idea perché (1) che potrebbe non essere un fileURL ben formato (ad esempio se il progetto viene estratto in una directory con caratteri insoliti), (2) il risultato è inutilizzabile se il POM di questo progetto viene utilizzato come dipendenza del progetto di qualcun altro.

Supponendo che tu non sia disposto a caricare l'artefatto in un repository pubblico, il suggerimento di Simeon di un modulo di supporto fa il suo lavoro. Ma ora c'è un modo più semplice ...

La raccomandazione

Usa plugin non-maven-jar-maven . Fa esattamente quello che stavi chiedendo, senza nessuno degli svantaggi degli altri approcci.

Ho trovato un altro modo per farlo, vedi qui da un post di Heroku

Riassumendo (scusate qualche copia e incolla)

• Crea una repodirectory nella cartella principale:

ProgettoUtente
+ - pom.xml
+ - src
+ - repo

• Eseguire questo per installare il jar nella directory repo locale

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

• Aggiungi questo tuo pom.xml:

<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>

Dopo aver discusso a lungo con i ragazzi di CloudBees sull'imballaggio ben fatto di questo tipo di JAR, hanno fatto una buona proposta interessante per una soluzione:

Creazione di un falso progetto Maven che collega un JAR preesistente come artefatto primario, eseguendo l'installazione di POM appartenuta: esecuzione del file di installazione. Ecco un esempio di tale tipo di 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>

Ma per implementarlo, la struttura del progetto esistente dovrebbe essere cambiata. Innanzitutto, dovresti tenere presente che per ogni tipo di JAR dovrebbe essere creato un progetto Maven (modulo) falso diverso. E dovrebbe essere creato un progetto Maven padre che includa tutti i sottomoduli che sono: tutti i wrapper JAR e il progetto principale esistente. La struttura potrebbe essere:

progetto root (questo contiene il file POM principale include tutti i sottomoduli con elemento XML del modulo ) (pacchetto POM)

Progetto figlio Maven wrapper JAR 1 (confezione POM)

JAR 2 wrapper Maven child project (packaging POM)

principale progetto figlio Maven esistente (confezione WAR, JAR, EAR ....)

Quando il genitore è in esecuzione tramite mvn: install o mvn: il packaging viene forzato e i moduli secondari verranno eseguiti. Questo potrebbe essere considerato un aspetto negativo qui, poiché la struttura del progetto dovrebbe essere modificata, ma alla fine offre una soluzione non statica

Quello che mi sembra più semplice è semplicemente configurare il tuo plugin-compilatore-maven per includere i tuoi vasetti personalizzati. In questo esempio verranno caricati tutti i file jar in una directory lib.

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

Il problema systemPathè che i barattoli delle dipendenze non verranno distribuiti lungo i tuoi artefatti come dipendenze transitive. Prova quello che ho pubblicato qui: è meglio creare i file jar del tuo progetto o metterli in WEB-INF / lib?

Quindi dichiarare le dipendenze come al solito.

E leggi la nota a piè di pagina.

Una strana soluzione che ho trovato:

usando Eclipse

• creare un progetto java semplice (non-maven)
• aggiungi una classe principale
• aggiungi tutti i barattoli al percorso di classe
• export Runnable JAR (è importante, perché non c'è altro modo per farlo)
• selezionare Estrai le librerie richieste nel JAR generato
• decidere i problemi di licenza
• tadammm ... installa il vaso generato sul tuo m2repo
• aggiungi questa singola dipendenza agli altri tuoi progetti.

saluti, Balint

Se vuoi una soluzione rapida e sporca, puoi fare quanto segue (anche se non lo consiglio per nulla tranne che per i progetti di test, Maven si lamenterà a lungo che questo non è corretto).

Aggiungi una voce di dipendenza per ogni file jar di cui hai bisogno, preferibilmente con uno script perl o qualcosa di simile e copia / incolla quello nel tuo file pom.

#! /usr/bin/perl

foreach my $n (@ARGV) {

    $n=~s@.*/@@;

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

Una soluzione batch rapida e sporca (basata sulla risposta di Alex):

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^>
)

Eseguirlo in questo modo: libs.bat > libs.txt. Quindi apri libs.txte copia il suo contenuto come dipendenze.

Nel mio caso, avevo solo bisogno delle librerie per compilare il mio codice e questa soluzione era la migliore per quello scopo.

Anche se non si adatta esattamente al tuo problema, lo lascerò qui. Le mie esigenze erano:

1. I barattoli che non possono essere trovati in un repository maven online dovrebbero trovarsi nell'SVN.
2. Se uno sviluppatore aggiunge un'altra libreria, gli altri sviluppatori non dovrebbero preoccuparsi di installarli manualmente.
3. L'IDE (NetBeans nel mio caso) dovrebbe essere in grado di trovare i sorgenti e javadocs per fornire il completamento automatico e l'aiuto.

Parliamo prima di (3): solo avere i vasetti in una cartella e in qualche modo fonderli nel vaso finale non funzionerà qui, poiché l'IDE non lo capirà. Ciò significa che tutte le librerie devono essere installate correttamente. Tuttavia, non voglio che tutti lo installino usando "mvn install-file".

Nel mio progetto avevo bisogno di metawidget. Eccoci qui:

1. Crea un nuovo progetto maven (chiamalo "librerie condivise" o qualcosa del genere).
2. Scarica metawidget ed estrai lo zip in src / main / lib.
3. La cartella doc / api contiene i javadocs. Crea una zip del contenuto (doc / api / api.zip).
4. Modifica il pom in questo modo
5. Compilare il progetto e la libreria verrà installata.
6. Aggiungi la libreria come dipendenza al tuo progetto o (se hai aggiunto la dipendenza nel progetto delle librerie condivise) aggiungi le librerie condivise come dipendenza per ottenere tutte le librerie contemporaneamente.

Ogni volta che si dispone di una nuova libreria, è sufficiente aggiungere una nuova esecuzione e dire a tutti di ricostruire il progetto (è possibile migliorare questo processo con le gerarchie del progetto).

Per installare il jar di terze parti che non si trova nel repository di maven, utilizzare maven-install-plugin.

Di seguito sono riportati i passaggi:

1. Scarica il file jar manualmente dall'origine (sito Web)
2. Crea una cartella e inserisci il tuo file jar in essa
3. Eseguire il comando seguente per installare il vaso di terze parti nel repository di Maven locale

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

Di seguito è riportato ad esempio quello che ho usato per simonsite log4j

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

4. Nel pom.xml includere la dipendenza come di seguito

     <dependency> 
           <groupId>uk.org.simonsite</groupId>
           <artifactId>log4j-rolling-appender</artifactId>
           <version>20150607-2059</version> 
     </dependency>

5. Esegui il comando mvn clean install per creare il pacchetto

Di seguito è riportato il link di riferimento:

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

Per coloro che non hanno trovato una buona risposta qui, questo è ciò che stiamo facendo per ottenere un barattolo con tutte le dipendenze necessarie in esso. Questa risposta ( https://stackoverflow.com/a/7623805/1084306 ) menziona l'uso del plugin Maven Assembly ma in realtà non fornisce un esempio nella risposta. E se non leggi fino alla fine della risposta (è piuttosto lunga), potresti perderla. Aggiungendo quanto segue al tuo pom.xml genereràtarget/${PROJECT_NAME}-${VERSION}-jar-with-dependencies.jar

        <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>

Ho accennato ad un po 'di codice Python in un commento alla risposta di @alex lehmann's, quindi lo sto postando qui.

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

Questo non risponde come aggiungerli al tuo POM e potrebbe essere un gioco da ragazzi, ma aggiungerebbe semplicemente la directory lib al tuo lavoro sul percorso di classe? So che è quello che faccio quando ho bisogno di un vaso esterno che non voglio aggiungere ai miei repository Maven.

Spero che sia di aiuto.

Ciò che funziona nel nostro progetto è ciò che Archimedes Trajano ha scritto, ma nel nostro .m2 / settings.xml abbiamo avuto qualcosa del genere:

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

e il * dovrebbe essere cambiato in centrale. Quindi se la sua risposta non funziona per te, dovresti controllare settings.xml

Volevo solo una soluzione rapida e sporca ... Non potevo eseguire lo script da Nikita Volkov: errore di sintassi + richiede un formato rigoroso per i nomi dei jar.

Ho creato questo script Perl che funziona con qualsiasi formato per i nomi dei file jar e genera le dipendenze in un xml in modo che possa essere copiato e incollato direttamente in un pom.

Se vuoi usarlo, assicurati di capire cosa sta facendo lo script, potrebbe essere necessario cambiare la libcartella e il valore per groupIdo artifactId...

#!/usr/bin/perl

use strict;
use warnings;

open(my $fh, '>', 'dependencies.xml') or die "Could not open file 'dependencies.xml' $!";
foreach my $file (glob("lib/*.jar")) {
    print "$file\n";
    my $groupId = "my.mess";
    my $artifactId = "";
    my $version = "0.1-SNAPSHOT";
    if ($file =~ /\/([^\/]*?)(-([0-9v\._]*))?\.jar$/) {
        $artifactId = $1;
        if (defined($3)) {
            $version = $3;
        }
        `mvn install:install-file -Dfile=$file -DgroupId=$groupId -DartifactId=$artifactId -Dversion=$version -Dpackaging=jar`;
        print $fh "<dependency>\n\t<groupId>$groupId</groupId>\n\t<artifactId>$artifactId</artifactId>\n\t<version>$version</version>\n</dependency>\n";
        print " => $groupId:$artifactId:$version\n";
    } else {
        print "##### BEUH...\n";
    }
}
close $fh;

La soluzione per l'approccio scope = 'system' in Java:

public static void main(String[] args) {
        String filepath = "/Users/Downloads/lib/";
        try (Stream<Path> walk = Files.walk(Paths.get(filepath))) {

        List<String> result = walk.filter(Files::isRegularFile)
                .map(x -> x.toString()).collect(Collectors.toList());

                String indentation = "    ";
                for (String s : result) {
                    System.out.println(indentation + indentation + "<dependency>");
                    System.out.println(indentation + indentation + indentation + "<groupId>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</groupId>");
                    System.out.println(indentation + indentation + indentation + "<artifactId>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</artifactId>");
                    System.out.println(indentation + indentation + indentation + "<version>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</version>");
                    System.out.println(indentation + indentation + indentation + "<scope>system</scope>");
                    System.out.println(indentation + indentation + indentation + "<systemPath>" + s + "</systemPath>");
                    System.out.println(indentation + indentation + "</dependency>");
                }

    } catch (IOException e) {
        e.printStackTrace();
    }
}