Maven e la libreria JOGL?

Ho studiato Maven nel mio tempo libero negli ultimi giorni ma non riesco a capire come organizzare un progetto in modo da utilizzare le librerie JOGL. Preferirei preferibilmente il seguente:

  1. Scarica automaticamente, se necessario, il file zip JOGL specifico del sistema operativo da qui (contiene 4 file jar e alcuni file di libreria nativi (.so / .dll)); o dipendere da un progetto Maven che è un wrapper di uno dei file.
  2. Decomprimere il file zip in modo appropriato, in modo che:
    1. i file jar vengono aggiunti al classpath e distribuiti come necessario, e
    2. i file della libreria nativa vengono aggiunti al file jar finale (questo consentirebbe loro di essere utilizzati automaticamente, o avrei bisogno di qualcosa di più coinvolto?)

Penso che parte del mio problema è che non capisco completamente l’uso di JOGL, dove posizionare le librerie native quando si esegue il codice, ecc. Ho bisogno di tornare alle basi e scrivere un mondo ciao JOGL, compilarlo da la riga di comando ed eseguila dalla riga di comando per vedere esattamente ciò che richiede per quanto riguarda il posizionamento di directory delle librerie native; Potrei farlo ora, in realtà.

Con l’elemento 1, ho trovato alcune funzionalità specifiche del sistema operativo; I profili Maven possono essere triggersti ​​in base alle proprietà del sistema, che includono il sistema operativo. Quindi potrei triggersre un profilo di Windows che ha una dipendenza dalla libreria JOGL specifica di Windows, lo stesso per Linux, ed entrambi hanno un alter ego a 64 bit. ( Documenti ufficiali di triggerszione / documenti non ufficiali .)

Ho provato a creare un repository Maven basato su un file jar JOGL e quindi ad aggiungere il progetto del file jar JOGL come dipendenza del mio progetto; la dipendenza viene scaricata, ma non utilizzata. Non ho idea di dove vada il file jar o come usarlo, scompattalo, ecc. Ecco il comando che ho usato.

Quindi, in breve: JOGL è composto da quattro file .jar e alcune librerie native. Come posso integrare questi file nel mio progetto Maven in modo che possa scrivere un’applicazione JOGL con Maven che gestisce il mio processo di compilazione? Inoltre, come posso utilizzare un diverso set di file a seconda del sistema operativo, perché ovviamente le librerie native e anche i file .jar differiscono tra Windows, Linux e Mac.

    Jogamp ora contiene il supporto per Maven, per i componenti di jogl (il supporto per jocl e joal è imminente). A partire da 2.0-rc11, i pacchetti vengono inviati a Maven Central.

    Metti questo al tuo pom:

      org.jogamp.gluegen gluegen-rt-main 2.0-rc11   org.jogamp.jogl jogl-all-main 2.0-rc11   

    Maven estrarrà tutte le dipendenze la prossima volta che tenterai di creare il progetto.

    Leggi di più qui sul wiki

    Quando si tratta di JNI e Maven, Progetti con JNI è il punto di riferimento con cui iniziare. Copre molto più del tuo attuale problema (che è “solo” usare una libreria che si basa su JNI e librerie native) ma, beh, chi può fare di più può fare di meno.

    Se lo leggete attentamente, vedrete che una soluzione per usare le librerie JNI è quella di raggrupparle in JAR specifici per l’architettura in modo che possiate dipendere da esse come qualsiasi altra dipendenza dal punto di vista di Maven. Questo è in realtà come JOGL versione 1.1.1 è impacchettato in http://download.java.net/maven/2/net/java/dev/jogl/ , c’è un artefatto JAR con le classi Java e diversi artefatti JAR specifici per l’architettura con le librerie native.

    Libreria JNI archiviata nel barattolo

    La soluzione che ho usato è stata quella di memorizzare la libreria jni compilata nel barattolo accanto ai file di class.

    Ciò significa eseguire una compilazione incrociata per tutte le possibili architetture o, più semplicemente, disporre di un jar diverso per ogni architettura. Quest’ultimo si adatta abbastanza bene al nostro setup – dove quasi tutte le nostre macchine sono Linux-i386, con un’infarinatura di scatole win32.

    Purtroppo System.load() non può far fronte al caricamento delle librerie da un jar, quindi avremo bisogno di un caricatore personalizzato che estrae la libreria in un file temporaneo in fase di runtime; questo è ovviamente raggiungibile, tuttavia.

    Quindi, come spiegato, l’idea è di usare un caricatore di librerie personalizzato per caricare la libreria nativa. La buona notizia è che un tale caricatore è “fornito” come spiegato di seguito.

    Caricatore di libreria

    Ora abbiamo la nostra libreria JNI sul percorso della class, quindi abbiamo bisogno di un modo per caricarla. Ho creato un progetto separato che estraeva le librerie JNI dal percorso della class, quindi le caricava. Trovalo su http://opensource.mxtelecom.com/maven/repo/com/wapmx/native/mx-native-loader/1.2/ . Questo è aggiunto come dipendenza dal pom, ovviamente.

    Per usarlo, chiama com.wapmx.nativeutils.jniloader.NativeLoader.loadLibrary(libname) . Ulteriori informazioni sono disponibili in javadoc per NativeLoader .

    Generalmente preferisco avvolgere queste cose in un blocco try / catch, come segue:

     public class Sqrt { static { try { NativeLoader.loadLibrary("sqrt"); } catch (Throwable e) { e.printStackTrace(); System.exit(1); } } /* ... class body ... */ } 

    Dovremmo ora essere al punto in cui i nostri test di unità di lavoro funzionano da esperti; un test mvn dovrebbe funzionare! Dovrebbe anche funzionare bene da un IDE.

    Ora, per rispondere alle tue domande, come:

    Scarica automaticamente, se necessario, il file zip JOGL specifico del sistema operativo da qui (contiene 4 file jar e alcuni file di libreria nativi (.so / .dll)); o dipendere da un progetto Maven che è un wrapper di uno dei file.

    Purtroppo, i jar JOGL 2.0 non sono disponibili nel repository Maven di java.net, quindi dovrai gestirli e renderli disponibili in un repository privato o installarli manualmente nel repository locale di ogni sviluppatore. Per fare ciò, usa mvn install:install-file come documentato nella Guida all’installazione di mvn deploy:deploy-file terze parti (e non mvn deploy:deploy-file come hai fatto, questo objective viene utilizzato per installare risorse in un repository remoto).

    Personalmente, vorrei scaricare JOGL 2.0 ZIP dall’URL che hai fornito, impacchettarlo come facevano con JOGL 1.1.1 (un JAR Java e diversi JAR specifici per le librerie native) e installare i JAR in ogni repository locale per ora. Quindi, dichiarare una dipendenza standard per l’artefatto Java e, in effetti, utilizzare i profili per la dipendenza specifica dell’architettura. Qualcosa come questo:

      ...   net.java.dev.jogl jogl 2.0-beta10  ...  ...   linux-i586   i386 unix linux     net.java.dev.jogl.jogl-linux-i586 jogl-linux-i586 2.0-beta10    ...  ...  

    Non dimenticare di aggiungere il repository richiesto per il caricatore della libreria personalizzata e la dipendenza:

        opensource.mxtelecom.com http://opensource.mxtelecom.com/maven/repo  ...  ...   com.wapmx.native mx-native-loader 1.2  ...  ...  

    Per quanto riguarda la seconda parte della tua domanda:

    Decomprimere il file zip in modo appropriato, in modo che (…)

    Come ho spiegato, in realtà non dipenderete dai file ZIP ma dai JAR e non avrete bisogno di decomprimerli né durante lo sviluppo né per distribuire il vostro progetto. Per la distribuzione, devi solo creare un barattolo che includa le dipendenze. Questo può essere fatto con il plugin maven-assembly-plugin. Vedi questa risposta per esempio per maggiori dettagli su questo.

    C’è un repository di notizie per JOGL 2.0 qui: http://jogamp.org/deployment/maven/

    Uso SBT per la costruzione dei miei progetti. Il resolver che devi aggiungere a build.sbt :

     resolvers += MavenRepository("jogamp", "http://jogamp.org/deployment/maven") 

    E la dipendenza, ad esempio, per la libreria jogl di base:

     libraryDependencies += "org.jogamp.jogl" % "jogl-all" % "2.0-rc9" 

    Nei file maven xml questo sarebbe qualcosa di simile (secondo questo ):

         jogamp  true    jogamp-remote jogamp test mirror http://www.jogamp.org/deployment/maven/ default      

    Con dipendenza dichiarata come:

      org.jogamp.jogl jogl-all 2.0-rc9  

    Per scaricare automaticamente un vero jar nativo, in SBT faccio qualcosa del tipo:

     sys.props("os.name") match { case "Linux" => "org.jogamp.jogl" % "jogl-all-natives-linux-i586" % "2.0-rc9" ... etc. ... 

    Non conosco la libreria JOGL ma ho esperienza con Java3d, che ha gli stessi problemi di installazione / costruzione. Ci sono due modi per ottenere questo:

    • dire agli sviluppatori di installare JOGL senza assistenza, quindi trattare le librerie JOGL come dipendenze di sistema come facciamo con Java3d

        javax.java3d j3dcore 1.5.1 system ${java.home}/lib/ext/j3dcore.jar  
    • posizionare tutti i contenitori e le librerie dipendenti dal sistema nel proprio repository e creare per essi i poms appropriati

    Se vuoi fortemente automatizzare con l’installazione di Maven di JOGL puoi provare ad usare maven-antrun-plugin o creare il tuo plugin Maven che gestisce l’installazione (un buon esempio è Cargo che scarica i server e lo decomprime).

    Considero di utilizzare la prima opzione: dire agli sviluppatori di installare JOGL. Nel nostro caso l’applicazione Java3d è distribuita da Java WebStart quindi per loro l’installazione di Java3d è completamente automatizzata da WebStart.

    Qui, per riferimento, è la parte del mio file Ant build.xml che scarica e decomprime la libreria JOGL (2.0 beta 10).

                                             Detected operating system: ${joglostype} (if invalid OS, update ant build file)                

    questo script scaricherà una versione da un URL e la installerà in un repository locale (denominato). https://gist.github.com/1624599

    esempio di utilizzo: ./install_jogl_maven http://jogamp.org/deployment/v2.0-rc5 path_to_local_repo 2.0-rc5

    Non c’è un modo semplice per farlo con. Prova a configurare il plugin maven-assembly- per creare un jar eseguibile e impacchettare i file corretti con il tuo codice. Non è ansible utilizzare la gestione delle dipendenze Maven per ottenere ciò poiché è necessario il contenuto della ZIP non lo stesso ZIP. Potresti provare il plugin maven-ant-ant .