2012-06-27 15 views
5

Supponiamo che io ho due progetti Java in Maven/Eclipse:Raggruppamento una dipendenza non-open-source con Maven

  • un'applicazione open source ospitato in GitHub
  • una piccola biblioteca privata contenenti funzioni di utilità che è non open source (ma che devo il diritto di modificare, creare e ridistribuire in forma compilata ad esempio come un file .jar)

mi piacerebbe rendere possibile per gli altri per costruire, modificare e eseguire l'applicazione on (e contribuire al progetto open source, se lo desiderano!), ma questo significa che avranno anche bisogno della libreria come dipendenza.

Mi piacerebbe mantenere le cose semplici, in modo che le build siano facili sia per me che per gli utenti dell'applicazione.

Qual è il modo più pratico per farlo funzionare?

risposta

3

Fornisci il tuo repository Maven su GitHub per distribuire la libreria closed source che ti è permesso di ridistribuire e referenziare dal tuo progetto (pom.xml).

http://cemerick.com/2010/08/24/hosting-maven-repos-on-github fornisce una bella introduzione su come impostare un repository su GitHub. Si dovrebbe essere consapevoli delle avvertenze di un tale micro repository menzionato anche in quel post.

+0

+1 Questo è il modo migliore per farlo! –

+0

C'è un modo per avere visibilità su chi o quante persone stanno scaricando le risorse da github? Sembra che Github raccolga solo le statistiche quando cloni il repository. – cosbor11

3

Quando si lavora con Maven si consiglia di utilizzare un gestore di Maven repository come Nexus e configurare il file di impostazioni, come descritto qui:

https://help.sonatype.com/display/NXRM3/Maven+Repositories#MavenRepositories-ConfiguringApacheMaven

Nella tua situazione ciò ha l'ulteriore vantaggio che si potrebbe usare il Maven Repository Manager per ospitare eventuali artefatti privati.

+0

hmmm ma in questo caso desidero che gli utenti open source pubblici siano in grado di utilizzare l'artefatto (idealmente senza hackerare le loro impostazioni). Qualche modo di farlo? – mikera

+0

non puoi mai essere sicuro che qualcuno non abuserà del tuo barattolo (decompilo) – ant

+0

ad es. per Nexus, devi rendere il gruppo pubblico accessibile a tutti (penso che questo sia l'impostazione predefinita se stai utilizzando un dominio/indirizzo IP pubblico) e assicurati che il tuo repository di hosting con la tua libreria privata sia in quel gruppo pubblico. Gli altri utenti possono quindi eseguire il proxy del repository nel proprio Maven Repository Manager. – Puce

3

Una soluzione davvero semplice sarebbe quella di collocare la libreria privata nel progetto (ad esempio <project>/lib/library-1.0.jar) e includerla come dipendenza system. Puoi includerlo nel tuo pom come.

<dependencies> 
    <dependency> 
     <groupId>my.private</groupId> 
     <artifactId>library</artifactId> 
     <version>1.0</version> 
     <scope>system</scope> 
     <systemPath>${project.basedir}/lib/library-1.0.jar</systemPath> 
    </dependency> 
    </dependencies> 

Attenzione: Una dipendenza sistema non è transitiv!

Dalla documentazione

Questo ambito è simile a condizione se non che è necessario fornire il JAR, che contiene in modo esplicito. L'artefatto è sempre disponibile e non è cercato in un repository.

+0

Grazie, molto utile. C'è un buon modo per aggiornare automaticamente il file jar della libreria se ricostruisco il progetto della libreria? – mikera

+0

Questa è una soluzione semplice, ma non è chiara, a causa dei problemi di transitività. Ma soddisfa la richiesta ... –

+0

@mikera Non so come semplificare l'aggiornamento della libreria. Se la tua libreria sarà rilasciata in una nuova versione devi fare qualcosa, anche con l'approccio del repository. Devi aggiornare il numero di versione della tua dipendenza nel tuo pom.xml (supponi di non utilizzare intervalli di versioni che rendono una build non riproducibile). – FrVaBe

Problemi correlati