¿Mejores prácticas para instalar bibliotecas de terceros en su repositorio alojado de Maven?

Question

Digamos que tiene un proyecto que está utilizando una biblioteca de terceros, como Google's Analytics Data API (gdata), que no parece estar implementado actualmente en los repositorios/índices públicos conocidos de Maven. Esto no es un gran problema, ya que puedo implementar el artefacto en mi repositorio Nexus hospedado localmente.

Pero, ¿hay alguna práctica recomendada en la comunidad Maven sobre cómo debo nombrar las "coordenadas" de esta biblioteca en mi POM, ya que un estándar no está ya configurado en repositorios públicos para ello?

Por ejemplo, debería refiero a ella en mi POM como

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

o hay alguna manera mejor/más estándar para mí para llegar a la artifactId?

(Y, ¿por qué diablos un proveedor de unas pocas docenas de bibliotecas como Google no se esforzará para alojarlas en los principales repositorios/índices públicos de Maven? ¿No sería esto más fácil para las personas usar ellos y así impulsar la adopción?)

Answer 1

Lo que has hecho es bastante razonable. Un par de puntos adicionales:

• Cuando Maven obtiene un artefacto de Nexus, el artefacto se nombran como artifactId-versión. GroupId se omite molestamente. Entonces, cuando el artefacto se mueve (digamos, copiado a WEB-INF/lib en una aplicación web), su archivo jar mostrará "gdata-analytics-1.0". Eso usualmente no es un problema. Sin embargo, si el nombre del artefacto es muy común, como "util", es posible que desee incluir información de grupo dentro de la artifactId, como el uso de groupId "com.google" y un artifactId de "com.google.gdata- análisis ". Sí, la repetición es molesta, pero proporciona la máxima claridad en el sistema de archivos y en las búsquedas. De hecho, tuve un problema donde dos groupIds diferentes tenían un jar "core-1.0" y uno sobrescribía el otro cuando se copiaba en el directorio lib en el momento de la compilación.

• I segundo Sugerencia de MattK de alinear su versión de Maven Id con la versión con la que se conoce comúnmente el artefacto.

• Si usted sigue los consejos de prefijar el groupId con su propio nombre de la empresa (por ejemplo, Acme) de Dominic, esto puede hacer que sea más fácil tomar ventaja de la función de envío de Nexus. Se asegurará de que las solicitudes de artefactos internos no se propagan a Maven Central y terminar en sus registros (que puede ser importante si su groupId es "acme.secret.project"!

Answer 2

He estado usando Maven durante aproximadamente un año y nunca he encontrado una convención de nomenclatura "estándar". Normalmente hago exactamente lo que estás haciendo, aunque trato de hacer que el número de versión sea lo más parecido posible al número de versión "real", solo para evitar confusiones en caso de que implemente varias versiones.

Answer 3

Tengo una tendencia a prefijar el groupId con mi propio groupId habitual. Esto deja absolutamente en claro que es algo que he subido, en caso de que se filtre al mundo en general.

Answer 4

Muchos sourceforge los proyectos usan el nombre del proyecto en groupid, por ejemplo:

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

Esto podría ser apropiado en el ejemplo de google, ya que hay muchos artefactos de Google.

Recuerde que puede usar una etiqueta classifer para diferenciar entre dos jarrones en la misma versión pero construido para diferentes propósitos, por ejemplo, diferentes JVM.

Answer 5

Es posible que en la suerte: Google tiene su propio repo Maven para sus proyectos. Ver esta página: Instructions

tuve algunos archivos JAR que estaban propietario, así que tuve que cargarlos en cada estación de trabajo (no tenemos un acuerdo de recompra compartida compañía aún). Los pongo en el árbol de código fuente en un directorio lib/(no siempre es una buena idea), y añadí un pequeño archivo .BAT (o script .sh) que contenía los comandos de instalación en archivos MVN para cargar repo de mi máquina local el primer tiempo que construyo Si alguna vez tengo que actualizar estos archivos jar, también actualizaré el archivo "load.bat" y simplemente lo volveré a ejecutar. En mi circunstancia, no espero que eso suceda más de una vez al año, tal vez menos.