2013-04-11 17 views
5

Ho diversi progetti che utilizzano Maven e vorrei eseguire un repository interno sulla mia rete di lavoro. Ho diverse librerie che sono di terze parti e non possono essere rilasciate in natura, così come alcune librerie nostre che devono essere disponibili all'interno della rete (incluso il nostro Server CI TeamCity) ma non possono essere implementate al di fuori della rete. Dopo un po 'di ricerche, ho trovato tre raccomandazioni principali su come ottenere questo risultato: Archiva, Artifactory e Nexus. Ho provato ciascuno di essi e non sono riuscito a ottenere una build di successo di nessuno dei miei progetti utilizzando i repository interni creati da nessuno di essi.Maven Internal Repository, è davvero così difficile?

Questo mi porta a credere che sto fraintendendo qualcosa o facendo qualcosa di sbagliato. Qualcuno sa di un tutorial che mi guiderà attraverso l'installazione e il repository Maven interno e integrarlo con il mio progetto?

+0

che guida avete già provato? Quali sono stati i tuoi problemi/errori con quei tre repository? –

+1

Dato che li hai trovati, potrebbe avere senso guardare la matrice di confronto - http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix – JBaruch

+0

Ci sono altre persone qui in SO chi comune su come utilizzare qualcosa di semplice come una cartella DropBox condivisa come repo privato, condiviso. Forse aiuto. –

risposta

4

Vorrei suggerire di utilizzare il Nexus evaluation guide (ultima versione disponibile è 2.13 ora) che viene fornito con il Nexus Pro Installer, ma funziona anche con Nexus Open Source per i semplici casi di utilizzo di proxy e di componenti che implementano.

Gli esempi sono disponibili anche su github e includono impostazioni per Maven, Ant/Ivy e Gradle. Una volta esaminati gli esempi e leggendo la guida, sarete in grado di impostare i vostri progetti allo stesso modo facilmente.

E, naturalmente, se ci sono problemi si può sempre ask on the mailing list or chat with the developers on hipchat

+0

L'hipchat era la chiave! Avevo una combinazione di problemi di memorizzazione nella cache di Maven, un proxy di repository mancante per un plug-in di terze parti e un po 'di antiquata stupidità. –

+0

Ho visto la chat nel registro. Molto bene. Sono felice che Ben e Kelly potrebbero aiutarti. –

+0

https://www.sonatype.com/books/nexus-book/reference/eval.html questo collegamento non funziona @ManfredMoser – tymbark

13

ho lavorato solo con Nexus, ma ho trovato molto facile da installare:

  1. Vai a http://www.sonatype.org/nexus/go per scaricare la versione OSS
  2. Prendi il 'guerra' di distribuzione
  3. Installare il servlet in la mia installazione di Tomcat, tramite Web Application Manager

A quel punto, posso visitare http://myserver:8080/nexus per vedere tutto funziona.

Per una configurazione superficiale, aggiungo la password di default alla mia settings.xml:

<servers> 
      <server> 
        <id>my-snapshots</id> 
        <username>admin</username> 
        <password>admin123</password> 
      </server> 
      <server> 
        <id>my-releases</id> 
        <username>admin</username> 
        <password>admin123</password> 
      </server> 
    </servers> 

e nel mio file POM:

<distributionManagement> 
      <snapshotRepository> 
        <id>my-snapshots</id> 
        <name>My internal repository</name> 
        <url>http://myserver:8080/nexus/content/repositories/snapshots</url> 
      </snapshotRepository> 
      <repository> 
        <id>my-releases</id> 
        <name>My internal repository</name> 
        <url>http://myserver:8080/nexus/content/repositories/releases</url> 
      </repository> 
    </distributionManagement> 

Per andare al di là di questo, la curva di apprendimento salta su un bel un po ', ma ho trovato i libri online di Sonatype abbastanza buoni. Repository Management with Nexus è quello per capire cosa è possibile fare con il server di repository. L'unica cosa che ho trovato difficile è che alcune informazioni si applicano solo al loro software commerciale e non funzionano troppo per pubblicizzare la differenza.

+3

Suggerirei di NON usare la guerra ma piuttosto il programma di installazione che includeva Nexus e Jetty (tar.gz o file zip). Sono contento che ti piaccia il libro. In termini di distinzione tra pro e oss ... questo è sul sito web. E aggiungiamo costantemente più cose a oss così come a professionisti e le cose cambiano in modo che il libro non faccia una grande distinzione. –

+0

@ManfredMoser Se hai una pagina che spiega i pro e i contro dell'uso dell'installer, sarebbe molto interessante. Sto facendo un uso molto semplice del Nexus OSS, e la mia esperienza è stata che la guerra è più semplice da aggiornare e richiede meno riflessioni da parte mia. È una differenza piuttosto piccola, però. –

+0

L'aggiornamento con il pacchetto è banale (http://www.sonatype.com/books/nexus-book/reference/install-sect-upgrading.html). Il vantaggio principale è che testiamo continuamente con il bundle e pro run sul bundle. Tutte le installazioni commerciali lo usano incluso jboss, ossrh e così via. La guerra non è supportata per i professionisti quindi sei praticamente da solo. Otterrete anche prestazioni migliori dal pontile in bundle .. –

7

I gestori di repository come Archiva e Nexus sono più di un semplice repository interno. Servono come proxy che impediscono di raggiungere Maven central o altri repository esterni.

Per un solo repository interno tutto ciò che serve è una posizione accessibile di rete o HTTP che abbia la struttura di un repository Maven. Quindi ti riferisci ad esso come un altro repository in your settings file.

<repository> 
    <id>my-internal-repo</id> 
    <url>http://myrepo.mycompany.com/</url> 
</repository> 

Vedere di più nella documentazione di Maven allo http://maven.apache.org/guides/introduction/introduction-to-repositories.html.

+0

NON si deve aggiungere un repository come repository. Questo ti dà solo un piccolo vantaggio. È molto meglio configurarlo come uno specchio globale. Maggiori informazioni qui http://www.sonatype.com/books/nexus-book/reference/config.html –

+0

@ManfredMoser Concordo sul fatto che Nexus è più di un repository. Infatti, anche io ** dico ** quello! Tuttavia la domanda iniziale era solo per un modo di ospitare JAR "interni". Ergo la mia risposta. Detto questo, rispettosamente non sono d'accordo con la tua affermazione "NON si dovrebbe aggiungere un server repository come repository". Questo ** è ** lo scopo fondamentale dell'impostazione 'repository'. –

+0

Beh, stai fraintendendo la procedura migliore per utilizzare la sezione mirror nel file settings.xml. Se si aggiunge un repository nel file delle impostazioni e non si utilizza la sezione mirror, tutte le richieste di componenti continueranno a essere nel repository centrale E si gestirà il repository. In questo modo si riducono le prestazioni e si perde il vantaggio di memorizzare nella cache i componenti da Central in Nexus. E il server dei repository sarà ancora un deposito per Maven. Inoltre, non è possibile aggiungere molti altri repository al proprio gruppo pubblico e tutti gli sviluppatori avranno accesso senza la necessità di modificare il proprio file di impostazioni. –