2013-03-09 17 views
24

Maven è fantastico. Per lo più mi tiene lontano dall'inferno della dipendenza da jar specificando le versioni dei pacchetti dipendenti nella configurazione pom e li applica automaticamente. Ha anche una grande integrazione con Eclipse via m2e, in modo che le cose funzionino perfettamente in un IDE.Maven ed eclipse: un modo affidabile per aggiungere vasi non Maven o esterni a un progetto?

Questo è tutto ottimo per le dipendenze che sono noti a livello mondiale a Maven. Tuttavia, a volte, ci sono librerie che devono essere incluse in un progetto che non è disponibile nei repository Maven. In questo caso, di solito li aggiungo a una directory lib/ nel mio progetto. Finché sono nel classpath, allora le cose si compilano.

Tuttavia, il problema è far sì che vengano inclusi automaticamente quando si importa un progetto. Ho tollerato questo problema con correzioni e hack a metà cottura per troppo tempo. Ogni volta che qualcuno installa questo progetto, devo dire loro di aggiungere manualmente i jar in lib/ al loro percorso di costruzione Eclipse in modo che tutti gli errori vadano a posto. Qualcosa di simile a quanto segue:

enter image description here

Sto cercando un modo per automatizzare questo processo in un modo che funziona sia con il programma a riga di mvn di comando e Eclipse: più l'accento su Eclipse, perché è bello avere progetti che si limitano a compilarli quando li si importa.

Non voglio configurare un server di pronti contro termine per questo, né ho alcun componente proprietario interno che giustifichi la configurazione di qualcosa localmente. Ho solo alcuni file jar in cui gli sviluppatori non usano Maven; e voglio compilare con loro ... dovrei essere in grado di includerli nella distribuzione del mio software, giusto?

Sono davvero alla ricerca di un modo ragionevole per implementare ciò che funzionerà anche in Eclipse senza problemi. This is one solution Ho trovato promettente, ma non sembra esserci una soluzione autorevole a questo problema. L'unica altra cosa che si avvicina è lo maven-addjars-plugin, che funziona bene, ma solo sulla riga di comando. Questo plugin non è male, e ha una configurazione abbastanza ragionevole:

<plugin> 
    <groupId>com.googlecode.addjars-maven-plugin</groupId> 
    <artifactId>addjars-maven-plugin</artifactId> 
    <version>1.0.5</version> 
    <executions> 
     <execution> 
      <goals> 
       <goal>add-jars</goal> 
      </goals> 
      <configuration> 
       <resources> 
        <resource> 
         <directory>${project.basedir}/lib/java-aws-mturk</directory> 
        </resource> 
        <resource> 
         <directory>${project.basedir}/lib/not-in-maven</directory> 
        </resource> 
       </resources> 
      </configuration> 
     </execution> 
    </executions> 
</plugin> 

Tuttavia, cercando di farlo correre in Eclipse comporta l'aggiunta del seguente pasticciare mappatura del ciclo di vita per il vostro pom.xml, che non ho mai avuto modo di lavorare; Non penso nemmeno che sia configurato per aggiungere qualcosa al percorso di costruzione di Eclipse.

<pluginManagement> 
    <plugins> 
     <!--This plugin's configuration is used to store Eclipse m2e settings only. It has no influence on the Maven build itself.--> 
     <plugin> 
      <groupId>org.eclipse.m2e</groupId> 
      <artifactId>lifecycle-mapping</artifactId> 
      <version>1.0.0</version> 
      <configuration> 
       <lifecycleMappingMetadata> 
        <pluginExecutions> 
         <pluginExecution> 
          <pluginExecutionFilter> 
           <groupId> 
            com.googlecode.addjars-maven-plugin 
           </groupId> 
           <artifactId> 
            addjars-maven-plugin 
           </artifactId> 
           <versionRange> 
            [1.0.5,) 
           </versionRange> 
           <goals> 
            <goal>add-jars</goal> 
           </goals> 
          </pluginExecutionFilter> 
          <action> 
           <execute /> 
          </action> 
         </pluginExecution> 
        </pluginExecutions> 
       </lifecycleMappingMetadata> 
      </configuration> 
     </plugin> 
    </plugins> 
</pluginManagement> 
+1

Preferirei fare affidamento su un'installazione locale nexus. –

+1

Voglio essere in grado di dare questo software ad altri da usare, quindi sembra irragionevole. Sono solo alcuni barattoli che voglio condividere, quindi non dovrebbe essere così complicato. –

+0

Nexus (o qualsiasi altra implementazione di repository) potrebbe aiutare il tuo processo di compilazione, quindi non sarebbe necessario per i tuoi utenti; mentre se sei FOSS, maven-izing le altre librerie e l'invio di patch a monte contribuirebbe alla comunità. Comunque, la tua scelta. –

risposta

45

1) è possibile utilizzare portata di un sistema di dipendenza

<dependency> 
     <groupId>test</groupId> 
     <artifactId>x</artifactId> 
     <version>1.0</version> 
     <scope>system</scope> 
     <systemPath>${basedir}/lib/x.jar</systemPath> 
    </dependency> 

2) è possibile copiare il x.jar al repository Maven locale come

repository/test/x/1.0/X- 1.0.jar

e aggiungere una dipendenza come

<dependency> 
     <groupId>test</groupId> 
     <artifactId>x</artifactId> 
     <version>1.0</version> 
    </dependency> 
+1

Questo è ESATTAMENTE quello di cui avevo bisogno. Rende inoltre disponibili i vasi per i progetti che dipendono da questo. Si integra perfettamente con Eclipse ed evita tutto questo gestione-repo e XML che tutti gli altri suggeriscono. Inoltre non implica copiare copie di merda nei repository Maven. +100 upvotes se potessi. –

+1

@Andrew Mao Fine se questa soluzione funziona per te. Fate attenzione al fatto che [le dipendenze degli scope di sistema sono simili alle dipendenze "fornite"] (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope). Pertanto, è previsto che esistano su una piattaforma di destinazione e non saranno inclusi nell'oggetto pacchettizzato (ad esempio file di guerra). – FrVaBe

+2

Ho scoperto che l'ambito del sistema influenza la gestione delle dipendenze transitori più a valle e non è possibile utilizzarlo. Credo che il modo corretto sia installare (manualmente o tramite script) gli artefatti di cui hai bisogno nel tuo repository locale. –

0

Mi sembra che si potrebbe usare il Maven Resources Plugin per fare questo per voi. Basta collegare la copia delle risorse a una fase del ciclo di vita appropriato (una fase precedente alla compilazione). È molto probabile che sia necessario modificare il plugin maven-compiler in modo che queste librerie si trovino sul classpath durante la compilazione e in fase di esecuzione.

5

È possibile utilizzare maven per installare i file da una cartella project \ lib al repository locale con il plugin maven-install-plug come indicato di seguito. Ho fatto questo prima con i driver JDBC. Potrebbe essere necessario creare un pom separato per esso ed eseguirlo con mvn -f installdeps.pom o qualcosa del genere.

Se riesci a farlo funzionare bene con un ciclo di vita come validare o qualcosa del genere, allora puoi usare il plugin m2e con Eclipse e potrebbe solo giocare bene e leggere le dipendenze direttamente dal pom.xml e installare i vasi come necessario per il repository locale.

<plugin> 
     <!-- We dont want children attempting to install these jars to the repo. --> 
     <inherited>false</inherited> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-install-plugin</artifactId> 
     <executions> 
      <execution> 
       <id>Microsoft JDBC Driver File 1</id> 
       <phase>install</phase> 
       <goals> 
        <goal>install-file</goal> 
       </goals> 
       <configuration> 
        <file>lib/sqljdbc4.jar</file> 
        <groupId>com.microsoft</groupId> 
        <artifactId>microsoft-jdbc-driver</artifactId> 
        <version>4.0</version> 
        <packaging>jar</packaging> 
       </configuration> 
      </execution> 
      <execution> 
       <id>ojdbc5</id> 
       <phase>install</phase> 
       <goals> 
        <goal>install-file</goal> 
       </goals> 
       <configuration> 
        <file>lib/ojdbc5.jar</file> 
        <groupId>com.oracle</groupId> 
        <artifactId>ojdbc5</artifactId> 
        <version>11.1.2</version> 
        <packaging>jar</packaging> 
       </configuration> 
      </execution> 
     </executions> 
    </plugin> 
Problemi correlati