È necessario materiale di presentazione per convincere un cliente a utilizzare Maven

Question

Il mio cliente ha bisogno di un inventario più organizzato di tutte le librerie di terze parti (come i file JAR) utilizzate in produzione per i propri progetti. Sono coinvolto in numerosi progetti basati su Java. Il loro inventario non è stato mantenuto in modo coerente nel passato e il tempo è giunto a rendere conto di tutte le librerie attualmente in uso (ce ne sono alcune!) E di imporre un processo strutturato per l'introduzione di nuove librerie nell'ambiente di generazione.

Ho provato a lanciare l'idea di utilizzare Maven e Artifactory nel loro processo di compilazione per sfruttare la capacità di questi strumenti di gestire un repository di librerie binarie e gestire le dipendenze della libreria transitiva. Il cliente è resistente al suggerimento perché pensa che creerà più lavoro per loro per mantenere un server Artifactory e apprendere le basi di Maven.

Attualmente, i loro progetti Java sono tutti costruiti utilizzando gli script Ant. Le dipendenze transitive sono in gran parte gestite da tentativi ed errori. L'inventario delle librerie attualmente in uso è gestito manualmente e i binari sono memorizzati in un repository Subversion. Il cliente riconosce che questo deve essere migliorato, ma gli attuali suggerimenti per il miglioramento implicano approcci più "gestisci a mano" ad hoc.

Voglio convincere il cliente che una combinazione di Maven e Artifactory è una valida soluzione pronta per le esigenze di gestione delle librerie Java. Qualcuno può indirizzarmi alla letteratura/ai materiali che posso utilizzare per creare una presentazione per il mio cliente sulle caratteristiche e sui punti di forza di Maven e Artifactory?

Qualsiasi altro argomento/suggerimento/ecc. Che potrebbe aiutarmi in questo sarebbe anche apprezzato.

Answer 1

Voglio convincere il cliente che una combinazione di Maven e Artifactory è una valida soluzione pronta per le loro esigenze di gestione delle librerie Java.

Come sottolineato in un commento, il cliente non ha necessariamente bisogno di adottare pienamente Maven di beneficiare di gestione delle dipendenze, si potrebbe adattare gli script ant esistenti per utilizzare il Maven Ant tasks o Ivy. Questo potrebbe essere meno spaventoso e rimuovere già un po 'di dolore.

Per quanto riguarda il modo in cui gestisce le dipendenze Maven, vorrei semplicemente spiegare che:

• Un artefatto è identificato da coordinate (groupId, artifactId, versione).
• Questo permette di memorizzare memorizzarle utilizzando una struttura di directory standard (un repository)
• Una dipendenza è più che un JAR: si tratta di un vaso con un POM che permette cose come la risoluzione delle dipendenze transitive.

E i vantaggi di tale soluzione sono la gestione delle dipendenze:

• non pasticciare con le dipendenze, si sono identificati univocamente (non più "quale versione si tratta?"Syndrom)
• dati più binari nel VCS (acquisti più velocemente, meno spazio)
• più facile riutilizzo dei manufatti tra i progetti (non più vasetti inviati per e-mail)
• più facile gestione con risoluzione transitiva delle dipendenze

E perché non si vuole fare affidamento su archivi pubblici, perché è necessario per memorizzare i propri manufatti, è necessario un repository aziendale la mia scelta personale sarebbe Nexus:.

• perché è file in base (a differenza Artifactory, e io non voglio mettere i miei artefatti in un database)
• perché è semplice da installare/utilizzare
• perché è facile da amministrare

Ecco alcune risorse su Nexus (mi dispiace, ho appena non uso Artifactory):

• Should we use Nexus or Artifactory for a Maven Repo?
• Ning’s Migration from Artifactory to Nexus Professional
• From Apache Archiva to Sonatype Nexus

E nel caso, ecco alcuni materiale di presentazione su Maven:

• Diversi presentations da Arnaud Héritier.
• Maven 2.x di Jason van Zyl.
• Maven 2.0 - Improve your build patterns di Vincent Massol.
• 3.5. Core Concepts nel Definitive Guide Maven