Con questo terzo articolo andremo a completare la panoramica sull’utilizzo di un repository maven remoto.

Inizialmente abbiamo analizzato i vantaggi di un’installazione dedicata, quindi abbiamo visto più nel dettaglio come effettuare una efficace configurazione del server, ora concluderemo con la configurazione necessaria per iniziare ad usare quanto realizzato finora.

Innanzitutto soffermiamoci sui punti chiave che vogliamo implementare.

• I nostri progetti maven devono sapere su quale repository andare ad uploadare il prodotto finale in fase di deploy.
• Agli sviluppatori deve essere concesso il solo upload di artefatti in versione SNAPSHOT (ovvero, come da articolo precedente, l’accesso tramite utente develop )
• Al tool di Build Automation deve essere concesso sia l’upload delle snapshot, sia di versioni stabili o “release” (accesso utente bamboo)

Per il primo punto quello che ci serve è configurare la sezione di distributionManagement dei nostri progetti maven.
Se avete gestito i vostri progetti in maniera gerarchica, potrete farlo inserendo il codice necessario semplicemente nel pom padre di tutti i progetti e vedere la configurazione automaticamente ereditata da tutti i figli.

<distributionManagement>
<repository>
<id>mycompany-release</id>
<url>http://${repo.baseurl}/artifactory/mycompany-release</url>
</repository>
<snapshotRepository>
<id>mycompany-snapshot</id>
<url>http://${repo.baseurl}/artifactory/mycompany-snapshot</url>
</snapshotRepository>
</distributionManagement>

Con questa configurazione i nostri progetti maven sapranno che una colta invocato il goal di deploy, gli artifact andranno uploadati sul nostro repository remoto, utilizzando il repository mycompany-snapshot per le SNAPSHOT, e il mycompany-release per le versioni stabili.

Ovviamente questo è quello che cercheranno di fare, in quanto la buona riuscita dell’operazione sarà vincolata ai permessi dell’utente che la effettuerà.

Passiamo quindi alla configurazione che il team di sviluppo dovrà utilizzare per utilizzare il repository.
Per gestire le configurazioni delle build , maven utilizza 2 files , entrambi chiamati settings.xml, il primo si trova nel folder di installazione di maven stesso, nella cartella conf, e rappresenta la configurazione globale di base.
Il secondo si trova all’interno della cartella .m2 nella home dell’utente che utilizza maven e rappresenta i settaggi locali dell’utente.
Noi andremo a modificare questo secondo file, inserendo i parametri che ci fornirà maven stesso.

Collegandosi infatti al nostro repository e scegliendo dal menu laterale Client configuraion -> Maven configuration ci troveremo su una pagina in grado di fornirci il 90% del file già pronto con i parametri che ci servono.

Impostate quindi la pagina come da screenshot e cliccate su Generate setting, quello che otterrete sarà un output come questo:

Come vedete il repository virtuale repo viene impostato come default per tutte le opzioni, snapshot e release, sia per gli artifact che per i plugin.
Sarà quindi artifactory stesso ad indirizzare sul repository corretto in base al fatto che l’oggetto richiesto sia una snapshot o una stabile.

Un’altra importante direttiva è il tag mirror in cima alla configurazione.
E’ infatti questa direttiva che sancisce il fatto che qualsiasi richiesta di un artifact venga fatta sempre e solo al nostro repository, delegando poi a lui la ricerca sugli altri archivi remoti.

L’unica sezione che dobbiamo aggiungere è quindi quella relativa all’autenticazione.
Senza di essa infatti navigheremmo il repository come utente anonymous, mentre vogliamo che i nostri sviluppatori possano accedere come developer.

Per i dettagli riguardanti l’encryption della password all’interno dei file di configurazione vi rimando alla guida ufficiale di maven, qui per brevità vi anticiperò solo che quello che dovrete aggiungere sarà una sezione come la seguente subito dopo il tag settings:

<server>
<id>mycompany-snapshot</id>
<username>developer</username>
<password>password123</password>
</server>

Grazie a questa direttiva maven saprà che ogni volta che si collegherà al repository con id mycompany-snapshot dovrà autenticarsi con le credenziali dell’utente in questione.
Qualora uno sviluppatore cercasse invece di collegarsi con le stesse credenziali al repo di release, non avrebbe invece i permessi di upload e otterrebbe solo errore di autorizzazione.

A questo punto ci manca solo la gestione del tool di build automation, ma l’implementazione non è diversa da quanto fatto per l’utenza developer, a parte ovviamente il fatto che il file settings.xml dovrà essere quello dell’utente applicativo del tool in questione (o comunque quello in esso configurato se differente) e che le credenziali dovranno essere quelle dell’utente bamboo.

Una volta aggiunta questa configurazione, qualsiasi deploy effettuato dal tool utilizzerà le corrette credenziali di accesso, uplodando quindi le SNAPSHOT su mycompany-snaphot (in maniera assolutamente analoga all’utente di sviluppo) ma anche gli artefatti di release nel repository mycompany-releases, sul quale nessun altra utenza potrà alterare il codice una volta completata la procedura.

Ogni artifact caricato sarà inoltre etichettato anche con l’utenza di provenienza, rendendo cosi immediata la distinzione tra SNAPSHOT caricate dagli sviluppatori e quelle provenienti invece dal tool di build automation.

 

E con questo possiamo dire di avere concluso la panoramica sull’utilizzo dei repository remoti di maven e sulle loro principali funzionalità, spero abbiate gradito la lettura e soprattutto vi siate lanciati nell’installazione del vostro repo personale! 😉