Le migliori pratiche per l'installazione di librerie di terze parti nel repository Maven ospitato?

Question

Diciamo che avete un progetto che utilizza una libreria di terze parti, ad esempio Google's Analytics Data API (gdata), che non sembra essere attualmente dispiegati in qualsiasi Maven archivi pubblici/indici ben noti o popolari. Questo non è un grosso problema, poiché posso semplicemente distribuire l'artefatto nel mio repository Nexus ospitato localmente.

Ma, ci sono delle migliori pratiche nella comunità di Maven per come dovrei nominare le "coordinate" di questa libreria nel mio POM, dal momento che uno standard non è già impostato nei repository pubblici per esso?

Per esempio, dovrei fare riferimento ad esso nel mio POM come

<dependency> 
    <groupId>com.google</groupId> 
    <artifactId>gdata-analytics</artifactId> 
    <version>1.0</version> 
</dependency> 

O c'è qualche/modo più standard migliore per me di venire con la artifactId?

(E, perché diamine, un fornitore di poche dozzine di librerie come Google deve fare uno sforzo per farli ospitare nei principali archivi/indici Maven pubblici? Questo non renderebbe più facile l'utilizzo da parte delle persone? loro e quindi guidare fino all'adozione?)

Answer 1

Quello che hai fatto è abbastanza ragionevole. Un paio di punti extra:

• Quando Maven ottiene un manufatto da Nexus, l'artefatto è chiamato come artifactId-versione. GroupId è fastidiosamente omesso. Quindi, quando l'artefatto viene spostato (ad esempio, copiato in WEB-INF/lib in un'app Web), il file jar leggerà "gdata-analytics-1.0". Questo di solito non è un problema. Tuttavia, se il nome del manufatto è molto comune, come "util", si consiglia di includere le informazioni di gruppo all'interno del artifactId, come l'utilizzo di groupId di "com.google" e un artifactId di "com.google.gdata- analytics ". Sì, la ripetizione è fastidiosa, ma offre la massima chiarezza sul file system e nelle ricerche. In realtà ho avuto un problema in cui due groupIs diversi avevano entrambi un jar "core-1.0" e uno sovrascriveva l'altro quando veniva copiato nella directory lib in fase di compilazione.

• ho secondo suggerimento di MattK di allineare il tuo Maven VERSIONID con qualsiasi versione del manufatto è comunemente conosciuto con.

• Se si segue il consiglio di Dominic di prefissare il groupId con il nome della propria azienda (es. Acme), può rendere più semplice sfruttare la funzione di routing di Nexus. Si farà in modo che le richieste di manufatti interni non vengono propagate verso Maven centrale e finire in loro registri (che può essere importante se il groupId è "acme.secret.project"!

Answer 2

Sto usando Maven per circa un anno e non sono mai imbattuto in una convenzione di denominazione "standard". Di solito faccio esattamente quello che stai facendo, anche se cerco di rendere il numero di versione il più vicino possibile al numero di versione "reale", solo per evitare confusione nel caso in cui disponga di più versioni.

Answer 3

Ho la tendenza a prefisso il groupId con il mio solito groupId. Questo rende assolutamente chiaro che è qualcosa che ho caricato, nel caso in cui si diffonde nel mondo.

Answer 4

Molti sourceforge i progetti utilizzano il nome del progetto nel groupid, ad esempio:

GroupId net.sf.json-lib ArtifactId json-lib

Questo potrebbe essere appropriato nell'esempio di google, in quanto vi sono molti artefatti di google.

Ricordare che è possibile utilizzare un tag Classifer per distinguere tra due vasi nella stessa versione ma creati per scopi diversi, ad esempio JVM diversi.

Answer 5

Potresti essere fortunato: Google ha il proprio repository Maven per i loro progetti. Vedi questa pagina: Instructions

Avevo alcuni file Jar che erano propietari, quindi ho dovuto caricarli su ogni workstation (non abbiamo ancora un repository condiviso dell'azienda). Li ho inseriti nell'albero del codice sorgente in una directory/lib (non sempre una buona idea) e aggiunto un piccolo file .BAT (o .sh script) che conteneva i comandi mvn install-file per caricare il repository della mia macchina locale il primo volta che costruisco. Se dovessi aggiornare questi jar, aggiornerò anche il file "load.bat" e lo eseguirò di nuovo. Nella mia circostanza, non mi aspetto che ciò accada più di una volta all'anno, forse meno.