Gestione delle dipendenze native più intelligente con Maven

Question

Attualmente sono nel bel mezzo della conversione di un grande progetto multi-modulo (~ 100 sottomoduli) per utilizzare Maven. Attualmente usiamo Ant + Ivy.

Finora non sono emersi problemi importanti e sono a mio agio che Maven è ancora una buona idea. Tuttavia, mi chiedo se esiste un modo migliore per gestire le dipendenze native.

Finora sono giunto alle seguenti conclusioni.

1. È meglio installare ciascuna dipendenza nativa nel repository Maven come libreria autonoma o pacchetto archiviato contenente più dipendenze.

2. Piuttosto che perdersi nel dichiarare ogni dipendenza con il plugin di dipendenza Maven, ho optato per dare ad ogni un classificatore (ad esempio nativi-win32) e utilizzare il seguente nella POM genitore:

    <plugin> 
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-dependency-plugin</artifactId> 
        <version>2.4</version> 
        <executions> 
         <execution> 
          <id>copy</id> 
          <phase>compile</phase> 
          <goals> 
           <goal>copy-dependencies</goal> 
          </goals> 
          <configuration> 
           <includeScope>runtime</includeScope> 
           <includeClassifiers>natives-win32</includeClassifiers> 
           <outputDirectory>${project.build.directory}/natives</outputDirectory> 
          </configuration> 
         </execution> 
        </executions> 
       </plugin> 
   

Finora questa sembra essere una semplice soluzione a tutto tondo che non richiede troppi problemi per aggiungere nuove dipendenze native. Mi offre anche una soluzione a tutto tondo per la gestione dei nativi. L'unica cosa che devo fare è assicurarsi che la mia directory/native/sia definita su java.library.path.

Una cosa che mi dà fastidio (un po ') di questo approccio è che tutte le mie dipendenze native vengono copiate in ogni sottomodulo che esprime una dipendenza transitiva su di esse, mentre le mie librerie jar felici vengono aggiunte al classpath a cui si fa riferimento dove si siedono nel mio deposito locale (nessuna copia richiesta).

Non c'è modo di essere più intelligente su questo e di far riferimento ai miei nativi dalla loro posizione di repository (presumendo che non li abbia archiviati, cioè dll). Ciò farebbe risparmiare un mucchio di copie inutili.

Ci sono altri potenziali trucchi che dovrei preoccuparmi dell'approccio sopra riportato?

Answer 1

Ho finito per usare il maven natives plugin e ho a che fare con il fatto che ho copie ridondanti delle librerie native intorno al luogo. Il motivo è dovuto principalmente alla semplicità offerta dal plug-in e al fatto che ha anche un plug-in di eclissi relativo che consente di impostare i nativi negli ambienti di eclipse degli sviluppatori senza alcun intervento.

Answer 2

Lo snippet mostra un obiettivo collegato a una fase di costruzione, non una dipendenza. L'obiettivo 'copia le dipendenze' in un super-pom ed è ereditato da tutti i moduli? Non c'è modo di spostarlo solo sui moduli che verranno eseguiti/pacchettizzati come app?

Answer 3

Potrebbe essere che non ce l'ho. Ma perché non distribuire tutte le librerie native nel repository all'inizio. Se le librerie native sono stabili e cambiano raramente, ciò potrebbe essere fatto in un reattore separato.

E successivamente si fa riferimento a tali dipendenze native semplicemente tramite GAV come qualsiasi altra dipendenza. Anche il problema di una copia non necessaria viene risolto da questo.