java - perfiles - ¿Cuáles son sus impresiones de Maven?

maven profiles properties example (18)

Estoy considerando usar Maven para un proyecto de código abierto de Java que administro.

En el pasado, sin embargo, Maven no siempre ha tenido la mejor reputación. ¿Cuáles son sus impresiones de Maven, en este momento?

@ MetroidFan2002: Maven 1 está en desuso y es posiblemente más estable que Maven 2 (aunque con menos funciones). Escribir guiones Jelly es definitivamente una mala idea.

Amo a Maven y lo uso todo el tiempo. Parte de la razón es que es muy simple de configurar a través de los complementos XML de Eclipse (tiene un XSD que es muy descriptivo). Maven también es ideal para la administración de dependencias, ya que le permite descargar archivos de repositorios y excluir dependencias transitivas cuando corresponda. También tiene un sitio incorporado: objetivo del sitio que es ideal para producir sitios web de proyectos con informes aplicables.

Maven es ideal para proyectos que recién están comenzando, pero tiene el formato esperado de su código fuente. Si comienza su proyecto con Maven, sabiendo lo que puede hacer inmediatamente, lo ayudará enormemente. Pero definitivamente debes investigarlo. "Out of the box", maven puede hacer grandes cosas y abundan los complementos para ello. Sin embargo, algunas cosas que ANT maneja mejor que Maven, y si no hay un plugin Maven para él, puede ser difícil de manejar en Maven. Pero, siempre puedes aprender a crear tu propio plugin Maven también.

Vea Better Builds With Maven para obtener una buena guía sobre maven.

Ah, y estos comentarios se aplican a Maven 2, nunca he usado Maven 1.

Hay algunas cosas muy buenas sobre maven:

Arquetipos: una especie de proyecto de inicio (base) (muy útil) que mucha gente hace. En las empresas donde tiende a recrear el mismo tipo de cosas una y otra vez, es extremadamente práctico.
Gestión de dependencias: realmente hay que intentar amarlo. Ivy es una buena herramienta compatible también.
Gestión del ciclo de vida: sin un IDE completo, puede hacer todo desde la línea de comandos con maven y quiero decir: compilar, empaquetar, probar, implementar, etc. Y es posible hacer que un paso dependa de otros. Aunque creo que los valores predeterminados no son los mejores, esta parte es personalizable.

Además, maven también puede hacer cosas de hormigas.

La desventaja para mí es realmente el hecho de que es difícil portar un proyecto. Lo mejor es comenzar desde cero. Además, maven utiliza ampliamente complementos para hacer su trabajo, pero no todo es perfecto en ese sentido y todavía no hay complementos para todo.

Maven se puede utilizar para gestionar todo el ciclo de vida de su proyecto, desde el inicio hasta la implementación. Si eso es lo que necesitas, entonces Maven es la herramienta adecuada. Si solo está buscando una herramienta para la administración de dependencias, es posible que también quiera investigar Ant Ivy .

Ha sido utilizado en la mayoría de los proyectos en los que trabajé y ... aunque a veces irritante (las configuraciones y la documentación), me ha ahorrado mucho tiempo. La mayoría de los proyectos basados en Java de Apache usan Maven.

Si Maven funciona, realmente depende de lo que quiere que haga por usted.

Para un proyecto de código abierto, Maven tiene algunas ventajas, especialmente para sus colaboradores (por ejemplo, mvn eclipse: eclipse).

Si vas con Maven, la única regla que debes seguir religiosamente es: no luches contra la herramienta. Diseñe su proyecto exactamente como recomienda Maven, siga todas sus convenciones y mejores prácticas. Cada pequeña pelea que te metas con Maven es un día en el que no gastarás en escribir el código para tu proyecto.

También considere de antemano dónde desea implementar sus artefactos (¿va a alojar su propio repositorio?).

Y no tengas miedo de ir con algo más que Maven (por ejemplo, Ant). El éxito de su proyecto será el proyecto en sí, no su herramienta de construcción (siempre y cuando elija la mejor herramienta de construcción, que tanto Ant como Maven).

Personalmente, no soy un fan. Estoy de acuerdo con la mayoría de lo que dice Charles Miller acerca de que está roto por diseño . Resuelve algunos problemas, pero también introduce otros .

Ant está lejos de ser perfecto, pero es mucho más robusto y está mucho mejor documentado. Sin embargo, se necesita cierta disciplina para usarlo de forma modular (que es una de las cosas que Maven intenta abordar). Creo que inventar algo mejor que Ant y Maven no sería tan difícil, pero esa herramienta no parece existir todavía.

Si te gusta la administración de dependencias de Maven pero no Maven, puedes obtener algo similar en Ant usando Ivy . Mi problema con este estilo de administración de dependencias es que es frágil debido a factores fuera de tu control. El caso de uso único en el que tiene algún sentido es si tiene muchos proyectos internos para su organización que dependen el uno del otro. En este caso, todo está bajo su control y podría funcionar bastante bien.

EDITAR : Olvidé agregar que incluso si no te gusta Maven, no puedes ignorarlo. Si escribe librerías de código abierto que otras personas usan, esperarán que estén disponibles en un repositorio Maven para que puedan usarlas fácilmente desde sus compilaciones Maven.

EDIT2 : Como has aclarado que tu interés principal es proporcionar una biblioteca de código abierto a otros usuarios de Maven, vale la pena señalar que no necesariamente tienes que usar Maven para lograr esto. Hay un conjunto de tareas Ant para publicar en un repositorio Maven . Por lo tanto, si desea continuar usando Ant para construir su proyecto, puede hacerlo pero aún así satisfacer a los usuarios que usan Maven.

Si su proyecto es "simple", maven le permite comenzar a usarlo rápidamente. Por simple quiero decir que tiene un montón de código, algunos recursos, algunas clases de prueba y todo va junto con algunos tarros de terceros para hacer una solicitud.

En el momento en que desee hacer algo inusual que sea de alguna manera específico para su propio proyecto, terminará gastando todo su tiempo tratando de hacer que Maven haga lo que quiera y sin perder tiempo trabajando con su código. Esto para mí derrota el propósito de usar un sistema de compilación inteligente.

Maven también es terrible para ayudarlo a diagnosticar problemas cuando no está funcionando. Y los scripts de compilación son reglas ilegibles de xml poco intuitivo y antinatural, que por supuesto puede ser lo que usted prefiera y esté buscando (si tiene antivisión).

Amo maven. Maven está lleno de bondad y promesa. También odio a maven.

Editar:

Ah, y el plugin maven para eclipse es flippin ''brillante.

Tuve la mala suerte de trabajar con Maven cuando estaba en transición de 1.x a 2.x. Casi consumió el 100% del tiempo de uno de nuestros miembros más veteranos del equipo. Finalmente lo descartamos.

Sin embargo, más recientemente tuve la oportunidad de volver a visitar Maven, y diría que ha mejorado. Uno de mis principales problemas ha sido la falta de buena documentación, pero después de leer "Maven: la guía definitiva" , diría que es mucho más fácil de entender.

Junto con el plugin m2eclipse para eclipse, administrar dependencias se convierte en un doddle, tiene una excelente herramienta de visualización de dependencias.

En general, diría que Maven es una gran herramienta para comenzar un proyecto, pero puede comenzar a perder su rumbo una vez que su construcción comience a ganar complejidad.

Una de las principales razones para usar cualquier herramienta de compilación es obtener compilaciones reproducibles. Es decir que la construcción que haces hoy se puede replicar exactamente en un tiempo. Maven, en mi experiencia, falla terriblemente en la prueba de crear compilaciones reproducibles.

Los problemas provienen de ser una bestia grande y compleja con muchas partes móviles. Cada parte tiene su propio ciclo de lanzamiento, y las versiones a menudo entran en conflicto entre sí y rompen su construcción. Tratar de depurar tal cosa es muy complejo.

Uso Maven para trabajos de código abierto porque produce un sitio web razonable con relativa rapidez. Eso es algo que rara vez interesa a los desarrolladores de código abierto. Incluso con esta tarea, con frecuencia he pasado largos períodos de tiempo tratando de descubrir por qué las cosas no funcionan como se esperaba. Para el trabajo de código abierto usualmente uso hormiga para producir realmente la compilación (jar) ya que es confiable.

Un punto final. Si está escribiendo un proyecto de código abierto, puede que tenga que usar Maven de alguna manera. Si tu proyecto es popular, entonces tendrás que obtenerlo en el repositorio central de Maven, y eso es mucho más complicado si no usas Maven.

estamos utilizando maven para un proyecto realmente grande (más de 15 módulos) y tratamos de no pelear con la herramienta, pero

1) maven resuelve el 90% de los problemas comunes, pero si estás luchando el otro 10% siempre es un desastre jugar con

2) la gestión del ciclo de vida es un desastre. Incluso si eliges una fase correcta para que tus cosas sucedan, a veces no funciona. Y no sabes la mierda por qué

3) luchamos duro pero finalmente nos damos por vencidos: usamos la hormiga de maven. A veces usamos incluso la hormiga para llamar a maven. Ahora ni siquiera intentes pensar que somos una mierda: si pudieras ver las complejidades de ciertos pasos en nuestro proceso de compilación ... es solo que Maven se interpone en tus caminos la mayoría de las veces para construir proyectos complejos.

4) la gestión del repositorio local es una carga. El artefacto no es bueno Y otros productos similares

Con todo: sugeriría Ant (tal vez con Ivy si quieres administración de dependencias, pero nunca lo intenté)

Bye Stefano

matt raible tiene una entrada de blog http://raibledesigns.com/rd/entry/comprehensive_project_intelligence_with_jason .

He oído que a la mayoría de las personas que usan Maven no les gusta.

Algunos amigos me han dicho que Maven es un poco como NetBeans: ambos sufren de cierto estigma que alguna vez se mereció pero ya no es completamente válido. Odiaba Maven 1.x debido a la falta de documentación y debido a XML / Jelly.

El último problema se puede resolver, ya que Maven 2 está mucho más orientado a Java. El estigma de la documentación deficiente persiste, pero no sé si es justo. ( Si todavía es justo, entonces el equipo de Maven realmente ha dejado caer la pelota.)

Tanto el POM como la administración de dependencias son buenas ideas, pero uno se pregunta si serán asimiladas por una herramienta más nueva, del mismo modo que C ++ abrió el camino a nuevos lenguajes.

Una nota final: la dicotomía entre Ant y Maven es algo falsa. Gradle y Gant son herramientas de compilación en el espacio Groovy que tienen mucho que ofrecer, incluso para proyectos directos de Java. Debido a que usan Groovy, las tareas simples son realmente simples (en contraste con las dolorosas construcciones XML en Ant); sin embargo, tienen una fuerte integración con Ant, por lo que existe un amplio conjunto de tareas "duras".

Personalmente me gusta mucho Maven, y hay muchas otras personas que también lo hacen. Maven2 tiene una reputación mucho mejor que Maven1, y parece que hay una tendencia en la comunidad OSS hacia eso. Para las tiendas que tienen muchos proyectos diferentes, realmente ayuda a crear consistencia y no sientes que estás reinventando la rueda con scripts Ant en cada proyecto.

Para abordar su pregunta, sería bueno que al menos envíe su jar al repositorio central. No tiene que reemplazar su proceso de compilación existente con maven, pero deberá mantener al menos un POM con las dependencias de su proyecto.

http://maven.apache.org/guides/mini/guide-central-repository-upload.html

Esto beneficiará a su proyecto al facilitar a los usuarios (que usan Maven o Ivy) descargar e instalar su jar.

Si decide usar maven para hacer su construcción, es probable que aumente la participación en su proyecto, ya que reducirá un poco la barrera de entrada. Una vez que haya construido su proyecto utilizando maven, todo lo que se requiere para alguien que quiera construir desde la fuente es ejecutar "mvn install". (FWIW, lo mismo se puede lograr usando Ant / Ivy hasta cierto punto).

Tenemos una comunidad de desarrolladores de código abierto que trabajan independientemente en sus propios proyectos. Varios de estos proyectos usan bibliotecas de otros proyectos. Sin gestión de dependencias, nos encontramos con dependencias cíclicas en frascos. La hormiga no ayudó con estos problemas (esto fue antes de Ivy, que no he usado). Al usar maven y desplegar jarras, estamos logrando reducir las dependencias y obtener muchos menos problemas. Así que nos hemos beneficiado enormemente de tener una herramienta de administración de dependencias y, personalmente, he descubierto que el esfuerzo por utilizar Maven vale mucho la pena.

En nuestra compañía, lentamente comenzamos a trasladarnos a Maven para tratar de imponer una uniformidad entre las diferentes construcciones de componentes. En este momento es una gran mezcla de guiones de hormigas tratando de hacer lo mismo. Funcionó muy bien, se integra muy bien con nuestro servidor de compilación (Hudson), y las pocas cosas que necesitábamos hacer que Maven no admite (o totalmente compatible), básicamente hemos incluido un xml de compilación de hormigas simplificado que adjuntamos a el proceso de construcción. Conecta todos los agujeros de la funcionalidad y hace la conversión a través de un sinch - Todo lo que tiene que trabajar es el proceso de compilación / paquete base, y luego puede pasar de cualquier efecto secundario de sus construcciones lentamente a medida que tenga tiempo.

La documentación está mejorando, y m2eclipse es simplemente increíble. Pero alguien arriba señaló el artículo "roto por diseño". Hizo algunos buenos puntos. Aunque personalmente creo que maven es una herramienta mejor que la hormiga, a la larga nuestra experiencia hará que maven3 sea una herramienta mejor que maven2.

No podría vivir sin eso. Puedo ir a CUALQUIER máquina en el mundo con una conexión a Internet, un JDK y Maven 2, revisar mi repositorio de git, y ejecutar ''mvn test'', y se compilará. Di eso sobre cualquier otra herramienta de construcción, te desafío. :-)

Una gran ventaja de usar Maven es que externaliza el ''modelo de objeto de proyecto'' (de ahí pom.xml ). La ventaja de una estructura de proyecto tan independiente es que se vuelve portátil entre las herramientas y los IDE.

Todos los principales IDE han invertido mucho en el apoyo de maven. Cuando abra el proyecto en su IDE de elección , adoptará la estructura Maven y estará listo:

En Eclipse : Importar ... Proyecto Maven ...
En IntelliJ : Abrir proyecto ... navegue al pom.xml
En Netbeans : todo de forma transparente

Normalmente coloca todos los metadatos IDE (.iml, .project, .classpath, etc ...) en la lista de ignorar de VCS .

Obviamente, los motores de Integración Continua se benefician de manera similar desde un enfoque basado en POM.

Hay una curva de aprendizaje y hay limitaciones, pero se obtiene mucho a cambio.

El JavaPosse discutió bastante sobre Maven en el podcast # 217 reciente . El consenso fue que es muy restrictivo en cuanto a cómo le permite estructurar sus proyectos, pero que su uso está creciendo y que puede ofrecer un estándar IDE cruzado para representar un proyecto.

Actualización -Javaposse también organizó una sesión informativa en la última primavera de Java Roundup 09 titulada, "¿Maven con dolor?" Me reí (con horrorizada simpatía) ya que, hacia el final de la grabación, uno de los participantes relató cómo una actualización de complemento rompió su compilación, dos días antes de la publicación de la producción.

Me he mantenido al margen, honestamente, en gran parte porque el nombre me resulta irritante. Sin embargo, la capacidad de administrar dependencias de bibliotecas de terceros es atractiva.

Actualización: para aquellos que tienen un desdén irracional por mi opinión irracional, permítanme mostrarles lo que "maven" evoca en mi mente:

Sí, en mi opinión, Edna Mode es el epítome de "maven". Y no la quiero en mi construcción, ¡demasiado mandona!

¿Cuál sería un nombre mejor? Las palabras inventadas son las mejores para sus resultados de Google puntuales. Para una buena impresión, cúbralos con palabras reales con una connotación positiva.