Suggerimenti per la gestione di un repository Maven interno?

Question

Sono interessato a mantenere un Maven 2 repository per la mia organizzazione. Quali sono alcuni dei suggerimenti e delle insidie ??che potrebbero aiutare.

Quali sono le linee guida che gli utenti devono seguire quando impostano gli standard per scaricare o pubblicare i propri artefatti nel repository quando rilasciano il loro codice? Che tipo di governance / regole hai in atto per questo tipo di cose? Cosa includi al riguardo nella guida / documentazione dello sviluppatore?

AGGIORNAMENTO : abbiamo difeso Nexus e ne siamo rimasti molto soddisfatti - abbiamo seguito la maggior parte delle linee guida di Sal e non abbiamo avuto problemi. Inoltre, abbiamo limitato l'accesso alla distribuzione e la creazione / distribuzione automatizzata di artefatti di istantanee attraverso un server CI Hudson. Hudson è in grado di analizzare tutte le dipendenze del progetto upstream / downstream, quindi se un problema di compilazione, un errore di test o qualche altra violazione causano l'interruzione della build, non si verificherà alcuna distribuzione. Sii stanco di fare distribuzioni di istantanee in Maven2 / Maven3, poiché i metadati sono cambiati tra le due versioni. Il solo "Hudson" la strategia di distribuzione dell'istantanea lo mitigherà. Non utilizziamo il plug-in di rilascio, ma abbiamo scritto alcune tubature intorno al Plug-in versioni quando per spostare un'istantanea da rilasciare. Usiamo anche m2eclipse e sembra funzionare molto bene con Nexus, poiché dal file delle impostazioni può vedere Nexus e sa indicizzare le informazioni sugli artefatti per la ricerca da lì. (Anche se ho dovuto modificare alcune di quelle impostazioni per indicizzare completamente le nostre istantanee interne.) Ti consiglio anche di distribuire un vaso sorgente con i tuoi artefatti come pratica standard se sei interessato a farlo. Lo configuriamo in un super POM.

AGGIORNAMENTO2 : Mi sono imbattuto in questo white paper Sonatype che descrive in dettaglio le diverse fasi di adozione / maturità, ognuna con obiettivi di utilizzo diversi per un gestore del repository Maven.

Answer 1

Consiglio di configurare un server Nexus con almeno quattro repository. Non consiglierei artificiale. La versione gratuita di Nexus è perfetta per un team di sviluppo inferiore a 20 in meno di tre gruppi. Se hai più utenti di così, fatti un favore e paga per la versione Sonatype. L'integrazione LDAP si ripaga da sola.

1. Rilascio interno
2. Istantanea interna
3. Terze parti interne per il codice utilizzato internamente da fonti esterne o per le versioni di terze parti approvate. Inserisci qui i driver JDBC, javax. * Roba e roba da clienti e partner.
4. Proxy esterni proxy comune per tutte le normali fonti come m2, codehaus ecc

Configura Nexus in modo che esegua i seguenti repository interni

1. Elimina le vecchie istantanee a intervalli regolari
2. Elimina istantanee al rilascio
3. Crea file indice. Questo accelera anche le build locali

Avere un file settings.xml comune che utilizza queste quattro e solo queste quattro fonti. Se è necessario personalizzare oltre questo, provare a mantenere una parte comune delle impostazioni archiviare e utilizzare i profili per le differenze. Non lasciare che i tuoi clienti cambino le proprie impostazioni o finirai con il codice che si basa su un computer ma non su qualsiasi altro computer.

Fornisci un proxy comune per i tuoi clienti. In Nexus, puoi aggiungere un gruppo di proxy ai comuni sorgenti Maven (Apache, JBoss, Codehaus) e avere un unico proxy esposto ai client interni . Ciò semplifica l'aggiunta e la rimozione di fonti dai tuoi clienti.

Non mescolare artefatti interni e di terze parti nello stesso repository. Nexus ti consente di aggiungere vasi a un repository interno tramite una GUI Web. Lo consiglio come modo per aggiungere i driver JDBC e altri codici esterni a terze parti. L'interfaccia utente è piuttosto piacevole da usare rispetto alla maggior parte dei software aziendali .

Definisci un POM principale comune che definisce l'istantanea interna e rilascia i repository tramite il tag distributionManagement . So che molte persone ti dicono di non farlo. E mentre ammetto liberamente che ci sono tutti i tipi di problemi nel farlo, funziona bene se i client costruiranno solo versioni e snapshot da distribuire in un singolo repository interno.

Se si dispone di un repository Maven gestito in modo errato , creare un quinto repository chiamato Legacy e inserire qui tutti i repository. Imposta un'attività cron per eliminare i vecchi file dall'eredità una volta che hanno un anno. Questo dà a tutti un anno di trasferirsi e aggiornare i loro poms.

Stabilisci una convenzione facile da rispettare per la denominazione di artefatti interni. Preferisco GroupID di Department.Function.Project e un ArtefactId per quel nome componente . Per i repository interni, è probabile che com / org / net e il nome della società siano irrilevanti. E sbagliato se la società cambia nome. È molto meno probabile che il reparto vendite, contabilità o inventario venga rinominato.

Answer 2

Usa sicuramente Nexus . : P

Ho usato sia Nexus che Artifactory. L'interfaccia per Nexus è molto più robusta, molto più configurabile e, naturalmente, scritta da Sonatype , che reputa praticamente tutto bene Maven.

Detto questo, Artifactory è decente e praticabile.

• Una recensione di Nexus vs. Artifactory
• Oh mio! Naturalmente, ecco un quesiton SO sulla questione.
• Sonatype esegue un confronto delle funzionalità
• jFrog (creatore di Artifactory) fa un confronto delle caratteristiche

Answer 3

Usa Artifactory .

Answer 4

Sto usando Artifactory da solo e adoro l'interfaccia utente e la facilità di implementazione / manutenzione. Detto questo, non ho mai usato Nexus e non posso davvero aiutarti con un corretto confronto delle funzionalità.

Qui ci sono alcune cose che mi piacciono molto di Artifactory (tieni presente che anche Nexus potrebbe avere queste caratteristiche):

1. Bella interfaccia Web 2.0.
2. La possibilità di importare il repository Maven locale per aiutarti a iniziare.
3. Facilità di integrazione con i server LDAP esistenti per motivi di sicurezza (sono un grande fan di un singolo repository per l'archiviazione delle credenziali).

Dato che ci sono davvero solo due importanti implementazioni del repository Maven là fuori, se vuoi davvero assicurarti di aver fatto la scelta giusta, ti consiglio di provare entrambi e decidere tu stesso quale ti piace di più.

Answer 5

Forse questo è ovvio, ma, per la riproducibilità, gli sviluppatori non dovrebbero mai sovrascrivere artefatti, dovrebbero essere nuove versioni.

Questo vale anche per i repository a monte. Se scarichi Apache-commons versione 1.2.3, non dovresti mai scaricarlo di nuovo. Le correzioni provengono dalle ultime versioni, non applicate alle versioni esistenti.

Answer 6

Qualcos'altro da considerare:

http://archiva.apache.org/

Answer 7

In quanto DOMANDA ORIGINALE (problemi tecnici da considerare quando si costruisce un repository M2), consiglierei di creare un utente di sola lettura per la navigazione nel repository e l'utente amministrativo per amministratore (che diceva: una lettura -solo utente per tutti quegli utenti che non sono amministratori). Inoltre, consiglierei di generare periodicamente immagini di backup (forse una volta al giorno?). Molto importante sia se il tuo repository è grande o se di tanto in tanto installi i tuoi artefatti.

Ultimo, ma non meno importante, quando si aggiungono nuovi repository remoti, è necessario aggiungere filtri di inclusione / esclusione in modo che una ricerca di artefatti nel repository venga eseguita più rapidamente.

Ci sono molti altri problemi da considerare, ma questi sono i problemi principali che ho riscontrato durante la gestione di un repository interno Maven.

Per la cronaca, sto usando sia Nexus che Artifactory; Posso affermare chiaramente che, sebbene Nexus sia molto semplice e operativo (anche se a volte ho problemi con il processo di installazione su Ubuntu), la sua versione gratuita non può competere con l'edizione della comunità (gratuita) di Artifactory. Escludendo la fantastica interfaccia utente Web 2 di Artifactory, le sue caratteristiche principali, come la gestione della sicurezza, i backup periodici e i problemi di accessibilità sono molto al di là di quelle di Nexus.