¿Por qué Maven tiene tan mala reputación? [cerrado]

Se habla mucho en Internet sobre lo malo que es Maven. He estado usando algunas funciones de Maven durante algunos años y, en mi opinión, el beneficio más importante es la gestión de dependencias.

La documentación de Maven es menos que adecuada, pero generalmente cuando necesito lograr algo, lo averiguo una vez y luego funciona (por ejemplo, cuando implementé la firma de los frascos). No creo que Maven sea genial, pero resuelve algunos problemas que sin él serían un verdadero dolor.

Entonces, ¿por qué Maven tiene una reputación tan mala y qué problemas con Maven puedo esperar en el futuro? ¿Quizás hay alternativas mucho mejores que no conozco? (Por ejemplo, nunca miré a Ivy en detalle).

NOTA: Este no es un intento de provocar una discusión. Es un intento de borrar el FUD.

Investigué a Maven hace unos seis meses. Estábamos comenzando un nuevo proyecto y no teníamos ningún legado que respaldar. Dicho eso:

• Maven es todo o nada. O al menos por lo que pude ver en la documentación. No puede usar maven fácilmente como un reemplazo directo de ant y adoptar gradualmente funciones más avanzadas.
• Según la documentación, Maven es la felicidad trascendental que hace realidad todos tus sueños más locos. Solo tienes que meditar en el manual durante 10 años antes de iluminarte.
• Maven hace que su proceso de construcción dependa de su conexión de red.
• Maven tiene mensajes de error inútiles. Compare el "Target x no existe en el proyecto y" de la hormiga con la "Tarea no válida 'ejecutar' de mvn: debe especificar una fase de ciclo de vida válida, o un objetivo en el formato plugin: goal o pluginGroupId: pluginArtifactId: pluginVersion: goal" Con ayuda, sugiere que ejecute mvn con -e para obtener más información, lo que significa que imprimirá el mismo mensaje, luego un seguimiento de pila para una BuildFailureException.

Una gran parte de mi disgusto por Maven se puede explicar por el siguiente extracto de Better Builds with Maven:

Cuando alguien quiere saber qué es Maven, suele preguntar "¿Qué es exactamente Maven?", Y espera una respuesta corta y sonora. "Bueno, es una herramienta de construcción o un marco de programación" Maven es más de tres palabras aburridas y poco inspiradoras. Es una combinación de ideas, estándares y software, y es imposible resumir la definición de Maven en simples fragmentos de sonido digeridos. Las ideas revolucionarias a menudo son difíciles de transmitir con palabras.

Mi sugerencia: si no puedes transmitir las ideas con palabras, no intentes escribir un libro sobre el tema, porque no voy a absorber telepáticamente las ideas.

• Te impone una estructura rígida desde el principio.
• Está basado en XML, por lo que es tan difícil de leer como lo fue ANT.
• Su informe de errores es oscuro y lo deja varado cuando las cosas salen mal.
• La documentación es pobre.
• Facilita las cosas difíciles y dificulta las cosas simples.
• Se necesita demasiado tiempo para mantener un entorno de compilación Maven, lo que anula el punto de tener un sistema de compilación que solo canta.
• Se necesita mucho tiempo para darse cuenta de que ha encontrado un error en maven y no ha configurado algo incorrecto. Y los bichos existen, y en lugares sorprendentes.
• Promete mucho pero te traiciona como una amante bella y seductora pero emocionalmente fría y manipuladora.

Ciertamente me quejé y me quejé de Maven en el pasado. Pero ahora, no estaría sin él. Siento que los beneficios superan con creces cualquier problema. Principalmente:

• Estructura de proyecto estandarizada.
  • Dado un nuevo desarrollador que se une a un proyecto:
    • Cuando dice que es un proyecto de Maven, el desarrollador conoce el diseño del proyecto y cómo construirlo y empaquetarlo.
    • Cuando dice que es un proyecto de Ant, el desarrollador tendrá que esperar a que le explique más o tendrá que pasar por build.xml para resolver las cosas.
  • Por supuesto, siempre es posible imponer el estándar de toda la empresa con Ant, pero creo que la mayoría de las veces, estará reinventando la rueda proverbial.
• Gestión de dependencias.
  • No solo con bibliotecas externas, sino también con bibliotecas / módulos internos. Asegúrese de utilizar un servidor proxy de repositorio de Maven como Nexus o Artifactory .
  • Es posible hacer algo de esto con Ivy . De hecho, si todo lo que necesita es una gestión de dependencias, probablemente sea mejor que utilice Ivy.
• Particularmente dentro de un proyecto. Me ha resultado bastante útil dividir pequeños subproyectos, y maven lo maneja bien. Es mucho más difícil con la hormiga.
• Gestión estandarizada de artefactos (especialmente junto con nexus o artefactorio )
• El complemento de lanzamiento es maravilloso.
• La integración de Eclipse y NetBeans es bastante buena.
• La integración con hudson es excelente. Particularmente los gráficos de tendencias para cosas como findbugs.
• Es un punto menor, pero el hecho de que maven incrusta detalles como el número de versión dentro del jar o war (no solo en el nombre del archivo) de forma predeterminada es tremendamente útil.

Las desventajas para mí son principalmente:

• La línea de comando es bastante inútil. Esto me desanimó mucho para empezar.
• El formato XML es muy detallado. Puedo ver por qué se hizo de esa manera, pero sigue siendo un dolor de leer.
  • Dicho esto, tiene un XSD para facilitar la edición en un IDE.
• Es difícil entenderlo al principio. Cosas como el ciclo de vida, por ejemplo.
  • Sin embargo, la guía definitiva de maven es una buena introducción.

Realmente creo que vale la pena dedicar un poco de tiempo a conocer a Maven.

Mi experiencia práctica de dos grandes proyectos es que hemos dedicado 1000 a 1500 horas para cada proyecto en problemas relacionados con maven, excluyendo un esfuerzo de 500 horas de pasar de maven 1 a maven 2.

Desde entonces, debo decir que odio absolutamente a Maven. Me siento frustrado al pensar en ello.

La integración de Eclipse es terrible. (Tuvimos problemas interminables con la generación de código, por ejemplo, donde eclipse se sincronizó con el código generado y requirió una reconstrucción completa, con bastante frecuencia. La culpa es tanto maven como eclipse, pero eclipse es más útil que maven y digamos emacs, así que El eclipse se queda y Maven tiene que irse.)

Teníamos muchas dependencias y, como descubrimos, los errores de sintaxis se cometen con bastante frecuencia en los repositorios públicos de maven, lo que puede arruinar horas de su valioso tiempo. Cada semana. La solución es tener un repositorio proxy o gobernado localmente y eso también tomó bastante tiempo para hacerlo bien.

La estructura del proyecto Mavens no es realmente adecuada para el desarrollo con Eclipse, y el tiempo de construcción en eclipse aumenta.

Como efecto de la generación de código y el problema de sincronización, tuvimos que reconstruir desde scrach con bastante frecuencia, reduciendo su ciclo de código / compilación / prueba a un ciclo de compilación / websurf / dormir / morir / código sin fin, enviándolo de regreso a los años 90 y Tiempos de compilación de 40 minutos.

La única excusa para maven es la resolución de dependencias, pero me gustaría hacerlo de vez en cuando, no en todas las compilaciones.

En resumen, maven está tan lejos de KISS como puede ser. Y también, los defensores tienden a ser el tipo de personas que celebran más en su cumpleaños cuando su edad es un número primo. No dudes en rechazarme :-)

Maven es genial. La razón de su reputación tiene que ver con la empinada curva de aprendizaje, en mi opinión. (que finalmente estoy cerca de superar)

La documentación es un poco difícil de leer, simplemente porque parece que hay mucho texto y cosas nuevas que comprender antes de que empiece a tener sentido. Yo digo que el tiempo es todo lo que se necesita para que Maven sea más elogiado.

Porque Maven es un dispositivo para reducir a los hombres adultos a masas sollozantes de absoluto terror.

Pros:

• Gestión de dependencias. Desde hace varios años, mis compañeros de trabajo y yo no descargamos ni administramos dependencias manualmente. Este es un gran ahorro de tiempo.
• Independencia IDE. Resulta que todos los IDE principales, Eclipse, IDEA y NetBeans tienen un soporte decente de los proyectos de Maven, por lo que nuestros desarrolladores no están limitados a un IDE en particular.
• Línea de comando. Con Maven, la compatibilidad con configuraciones IDE y de línea de comandos simultáneas es sencilla, lo que es bueno para la integración continua.

Contras:

• Tienes que invertir en aprender Maven. Bueno, tengo que hacerlo. Buenas noticias, no todos los miembros del equipo tienen que aprender.
• Documentación. Solía ​​ser un problema, ahora gracias a Sonatype y su libro ( http://www.sonatype.com/products/maven/documentation/book-defguide ), la situación es mucho mejor.
• Rigidez. A veces es desafiante y frustrante hacer las cosas de la manera que desea. Mi consejo sería no pelear y obligar a Maven a hacer las cosas que mejor hace, construcciones sencillas o cuando haya un mojo estable disponible. En otros casos, abandonamos y hacemos cosas con tareas Ant ( http://maven.apache.org/plugins/maven-antrun-plugin/ ) o programas externos. Mi favorito personal es Groovy plugun ( http://groovy.codehaus.org/GMaven ).

Competencia:

• Ant: no tiene gestión de dependencias. Período.
• Ivy: aún menos madura que Maven (no es que esta última no tenga sus peculiaridades también). Casi el mismo conjunto de funciones, por lo que no hay una razón de peso para mudarse. Hice varios intentos para probarlo; todo fallido.

En pocas palabras: todos nuestros proyectos se realizan con Maven desde hace varios años.

Creo que tiene mala reputación entre las personas que tienen los proyectos más simples y complicados.

Si está creando un solo WAR a partir de una única base de código, lo obliga a mover la estructura de su proyecto y enumerar manualmente los dos o tres frascos en el archivo POM.

Si está construyendo un EAR a partir de un conjunto de nueve prototipos de archivos EAR con una combinación de cinco archivos WAR, tres EJB y otras 17 herramientas, jarras de dependencia y configuraciones que requieren ajustar los archivos MANIFEST.MF y XML en los recursos existentes durante la compilación final; entonces es probable que Maven sea demasiado restrictivo. Un proyecto de este tipo se convierte en un lío de complicados perfiles anidados, archivos de propiedades y mal uso de los objetivos de compilación de Maven y la designación del clasificador.

Entonces, si estás en el 10% inferior de la curva de complejidad, es exagerado. En el 10% superior de esa curva, estás en una camisa de fuerza.

El crecimiento de Maven se debe a que funciona bien para el 80% medio

Mi experiencia refleja la frustración de muchas de las publicaciones aquí. El problema con Maven es que envuelve y oculta los detalles de la gestión de compilación en su búsqueda de la máxima bondad automágica. Esto lo deja casi indefenso si se rompe.

Mi experiencia es que cualquier problema con maven degeneró rápidamente en una búsqueda de disparos de varias horas a través de redes de archivos xml anidados, en una experiencia similar a la del tratamiento de conducto.

También trabajé en tiendas que dependían mucho de Maven, la gente a la que le gustaba (a la que le gustaba por el aspecto de "pulsa un botón, hazlo todo") no lo entendía. Las compilaciones de maven tenían un millón de objetivos automáticos, lo que estoy seguro de que sería útil si quisiera tomarme horas para leer lo que hicieron. Mejores 2 objetivos que funcionen y que comprenda completamente.

advertencia: la última vez que trabajé con Maven hace 2 años, puede que sea mejor ahora.

Como Glenn, no creo que Maven tenga una mala reputación, sino una reputación mixta. He estado trabajando durante 6 meses exclusivamente tratando de migrar un proyecto de proyecto bastante grande a Maven y muestra claramente los límites de la herramienta.

En mi experiencia, Maven es bueno para:

• gestión de la dependencia externa
• gestión centralizada de la construcción (herencia pom)
• muchos complementos para muchas cosas
• muy buena integración con herramientas de integración continua
• muy buenas capacidades de generación de informes (FindBugs, PMD, Checkstyle, Javadoc, ...)

Y tiene algunos problemas con:

• enfoque de todo o nada (difícil de migrar lentamente a Maven)
• dependencias complejas, dependencias entre módulos
• dependencias cíclicas (lo sé, mal diseño, pero no podemos arreglar 5 años de desarrollo ...)
• coherencia (los rangos de versiones no funcionan igual en todas partes)
• errores (nuevamente con rangos de versiones)
• compilaciones reproducibles (a menos que arregle el número de versiones de todos los complementos, no puede estar seguro de que obtendrá la misma compilación en 6 meses)
• falta de documentación (el documento es bastante bueno para lo básico, pero no hay muchos ejemplos de cómo manejar proyectos grandes)

Para dar un poco de contexto, hay alrededor de 30 desarrolladores trabajando en este proyecto, y el proyecto ha existido por más de 5 años, entonces: mucho legado, muchos procesos ya implementados, muchas herramientas propietarias personalizadas ya implementadas. Decidimos intentar migrar a Maven porque el costo de mantener nuestras herramientas patentadas era demasiado alto.

Me gustaría contrarrestar algunas de las quejas presentadas en este foro:

Maven es todo o nada. O al menos por lo que pude ver en la documentación. No puede usar maven fácilmente como un reemplazo directo de ant y adoptar gradualmente funciones más avanzadas.

Eso no es cierto. La gran ventaja de Maven es usarlo para administrar tus dependencias de una manera racional y si quieres hacerlo en Maven y hacer todo lo demás en Ant, puedes hacerlo. Así es cómo:

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />
  </maven:dependencies>
</project>

Ahora tiene un objeto classpath llamado 'maven.classpath' que contiene todas las dependencias maven definidas en el archivo pom. Todo lo que necesita es poner el tarro de tareas de hormiga maven en el directorio lib de su hormiga.

Maven hace que su proceso de construcción dependa de su conexión de red.

La dependencia predeterminada y el proceso de obtención de complementos depende de una conexión de red, sí, pero solo para la compilación inicial (o si cambia las dependencias o complementos en uso). Después de eso, todos los frascos se almacenan en caché localmente. Y si desea forzar la conexión sin red, puede decirle a maven que use el modo fuera de línea.

Te impone una estructura rígida desde el principio.

No está claro si esto se refiere al formato de archivo o al problema de "convención versus configuración". Para este último, hay muchos valores predeterminados invisibles como la ubicación esperada de los archivos y recursos fuente de Java, o la compatibilidad de la fuente. Pero esto no es rigidez, es poner valores predeterminados razonables para que no tenga que definirlos explícitamente. Todas las configuraciones se pueden anular con bastante facilidad (aunque para un principiante puede ser difícil encontrar en la documentación cómo cambiar ciertas cosas).

Si está hablando del formato de archivo, bueno, eso se cubre en la respuesta a la siguiente parte ...

Está basado en XML, por lo que es tan difícil de leer como lo fue ANT.

En primer lugar, no veo cómo puede quejarse de que algún aspecto de algo "no es mejor que una hormiga" como justificación para que tenga una mala reputación. En segundo lugar, aunque sigue siendo XML, el formato del XML es mucho más definido. Además, debido a que está tan definido, es mucho más fácil hacer un editor de cliente grueso y sensato para un POM. He visto páginas largas de guiones de construcción de hormigas que saltan por todos lados. Cualquier editor de secuencias de comandos de construcción de hormigas no lo hará más aceptable, solo otra larga lista de tareas interconectadas presentadas de una manera ligeramente diferente.

Habiendo dicho eso, hay algunas quejas que he visto aquí que tienen o han tenido alguna validez, la más grande es

• La documentación es deficiente / falta
• Construcciones reproducibles
• La integración de Eclipse es mala
• Loco

A lo que mi respuesta es doble. En primer lugar, Maven es una herramienta mucho más joven que Ant o Make, por lo que debe esperar que lleve tiempo llegar al nivel de madurez de esas aplicaciones. En segundo lugar, bueno, si no te gusta, arréglalo . Es un proyecto de código abierto y usarlo y luego quejarse de algo que cualquiera puede ayudar a resolver me parece bastante estúpido. ¿No te gusta la documentación? Contribuya a que sea más claro, más completo o más accesible para un principiante.

El problema de compilaciones reproducibles se divide en dos problemas, rangos de versiones y actualizaciones automáticas de complementos de maven. Para las actualizaciones del complemento, bueno, a menos que se esté asegurando cuando reconstruya un proyecto un año después de que está usando exactamente el mismo JDK y exactamente la misma versión de Ant, bueno, este es el mismo problema con un nombre diferente. Para los rangos de versiones, recomiendo trabajar en un complemento que produzca un pom temporal con versiones bloqueadas para todas las dependencias directas y transitivas y que lo haga parte del ciclo de vida de la versión de maven. De esa manera, los poms de compilación de su lanzamiento son siempre descripciones exactas de todas las dependencias.

Se merece la reputación que tiene. No todo el mundo necesita la estructura rígida que los desarrolladores de Maven pensaban que era adecuada para cada proyecto. Es tan inflexible. Y lo que es 'Pro' para muchas personas, la gestión de la dependencia, es en mi humilde opinión su mayor 'estafa'. No me siento absolutamente cómodo con maven descargando los archivos jar de la red y pierdo el sueño por incompatibilidades (sí, el modo fuera de línea existe, pero entonces ¿por qué debería tener todos esos cientos de archivos xml y sumas de verificación)? Decido qué bibliotecas utilizo y muchos proyectos tienen serias preocupaciones sobre las compilaciones que dependen de la conexión de red.

Y lo que es peor, cuando las cosas no funcionan, estás absolutamente perdido. La documentación apesta, la comunidad no tiene ni idea.

Un año después, quería actualizar esto: ya no tengo esta opinión sobre la comunidad de Maven. No escribiría esta respuesta si la pregunta se hiciera hoy. Voy a agregar mi opinión actual como una respuesta separada.

Esta es una respuesta muy subjetiva, pero la pregunta es sobre opiniones, así que ...

Me gusta Maven, y me gusta más cuanto más lo conozco. Sin embargo, una cosa que afecta mis sentimientos al respecto: la comunidad de maven se centra principalmente en Sonatype ("la empresa de maven", es donde muchos de los líderes de Maven están trabajando), y Sonatype está impulsando sus productos corporativos de manera bastante agresiva en la comunidad.

Un ejemplo: el flujo de Twitter "Maven Book" enlaza con una supuesta introducción a la gestión de repositorios .

Lo siento, pero esa "introducción" es mitad información, mitad argumento de venta para Nexus. Examen sorpresa: ¿hay otros administradores de repositorios además de Nexus y Nexus Pro? Además, ¿qué tiene eso que ver con el libro Maven supuestamente de código abierto? Oh, cierto, el capítulo sobre administración de repositorios se ha convertido en un libro separado ... sobre Nexus. ¿Eh? Si contribuyo al libro de Maven, ¿obtengo una tarifa de referencia si causo un aumento en las ventas de Nexus?

Imagínese si estuviera participando en un foro de desarrollo de Java y estuviera claro que los empleados de Sun discutiendo sobre Java aprovecharían todas las oportunidades posibles para hablar sobre NetBeans y "NetBeans Pro". Después de un tiempo, pierde algo de su sentimiento de comunidad. Nunca tuve una experiencia como esa con Ant.

Habiendo dicho todo eso, creo que Maven es un sistema muy interesante y útil (no lo llamo una herramienta, como lo es Ant, Maven es más amplio que eso) para la configuración del desarrollo de software y la gestión de compilaciones. La gestión de la dependencia es una bendición y una maldición a veces, pero es refrescante, y ciertamente no es la única ventaja que ofrece Maven. Probablemente estoy reaccionando con demasiada fuerza al chelín de Sonatype, pero en mi opinión, a Maven le duele por asociación. No sé si alguien más comparte esta opinión.

Creo que Maven tiene mala reputación porque impone una estructura a tu proyecto, mientras que otras herramientas como Ant te permiten definir completamente la estructura de la forma que desees. También estuve de acuerdo en que la documentación es mala, pero creo que principalmente la mala reputación que recibe Maven se debe a que la gente está muy acostumbrada a Ant.

Demasiada magia.

Porque la gente insatisfecha se queja, mientras que la gente satisfecha no dice estar satisfecha. Mi punto es que hay muchos más usuarios de maven satisfechos que insatisfechos, pero los últimos hacen más ruido. Este también es un patrón común de la vida real (ISP, operador de telefonía, transportes, etc., etc.).

El problema más importante para mí es que Maven, cuando no se configura correctamente, puede no producir compilaciones repetibles debido a:

• repositorios remotos poco fiables;
• dependencias de complementos y bibliotecas con versiones SNAPSHOT o sin versiones.

Contraste esto con una construcción de hormigas que, aunque en mi opinión, verbosa y tediosa, funciona ya que todos los frascos se registran localmente.

Lo bueno es que los problemas son abordables:

• use su propio repositorio de maven, que se ha vuelto muy simple, estoy usando Archiva con buenos resultados;
• siempre versione correctamente sus dependencias. Maven ha comenzado a bloquear las versiones de complementos en el super-POM a partir de 2.0.8 o 2.0.9 y todas sus dependencias deben estar en las versiones publicadas.

gran idea - mala implementación.

Recientemente mudé un proyecto de Ant a Maven. Funcionó bien al final, pero tuve que usar dos versiones diferentes de maven-assembly-plugin y maven-jar-plugin en el mismo pom (obtuve dos perfiles) porque lo que funcionó en una versión se rompió en otra.

Así que fue todo un dolor de cabeza. La documentación no siempre es excelente, pero debo admitir que fue relativamente fácil buscar respuestas en Google.

asegúrese de especificar siempre las versiones de los conectores que utiliza. No espere que la nueva versión sea compatible con versiones anteriores.

Creo que la controversia proviene del hecho de que maven todavía evoluciona y el proceso a veces es doloroso.

Saludos

v.

Me gusta Maven. Lo he usado desde pre 1.0. Es una herramienta poderosa que, a fin de cuentas, me ha ahorrado una cantidad considerable de tiempo y ha mejorado mi infraestructura de desarrollo. Pero puedo entender la frustración que sienten algunas personas. Veo 3 tipos de frustración:

1. donde las causas son preocupaciones reales (por ejemplo, POM detallados, sin documentación),
2. algo es información errónea (por ejemplo, "debe tener una conexión a Internet para construir" - no es cierto - no, esto se puede evitar),
3. algo de esto se desahoga en maven pero en realidad alguien más es culpable ("no dispares al mensajero").

Para el primer caso, problemas reales, bueno, claro, hay problemas, los POM son detallados, la documentación podría ser mejor. Sin embargo, a pesar de esto, es posible obtener buenos resultados con maven en poco tiempo. Me estremezco cada vez que construyo un proyecto con ant y trato de importarlo a mi IDE. Puede llevar mucho tiempo configurar la estructura de directorios. con maven, es solo un caso de abrir el archivo POM en el IDE.

Para el segundo caso, Maven es complejo y los malentendidos son comunes. Si maven 3 puede encontrar una manera de abordar esta complejidad (o incluso la complejidad percibida), sería bueno. maven requiere una inversión considerable, pero, en mi experiencia, la inversión se amortiza rápidamente.

Para el último punto, creo que la queja sobre las dependencias transitivas de maven es probablemente el ejemplo más conocido.

Las dependencias transitivas son la naturaleza del software real que emplea la reutilización. Las DLL de Windows, los paquetes Debian, los paquetes Java, los paquetes OSGi, incluso los archivos de encabezado C ++ tienen dependencias y sufren el problema de la dependencia. Si tiene dos dependencias y cada una usa una versión diferente de lo mismo, entonces debe intentar resolverlo de alguna manera. Maven no intenta resolver el problema de la dependencia, sino que lo pone en primer plano y proporciona herramientas para ayudar a gestionar el problema, como informar conflictos y proporcionar dependencias coherentes para una jerarquía de proyectos, y de hecho proporciona un control absoluto sobre las dependencias de un proyecto.

El enfoque de incluir manualmente las dependencias con cada proyecto (un cartel dice que verifica todas las dependencias en el control de fuente) corre el riesgo de usar la dependencia incorrecta, como actualizaciones pasadas por alto cuando una biblioteca se actualiza sin registrar actualizaciones para sus dependencias. Para un proyecto de cualquier tamaño, administrar las dependencias manualmente seguramente dará lugar a errores. Con maven, puede actualizar la versión de la biblioteca que usa y se incluyen las dependencias correctas. Para la gestión de cambios, puede comparar el antiguo conjunto de dependencias (para su proyecto como un todo) con el nuevo conjunto, y cualquier cambio puede ser examinado, probado, etc.

Maven no es la causa del problema de dependencia, pero lo hace más visible. Al abordar los problemas de dependencia, maven hace que cualquier "ajuste" de dependencia sea explícito (un cambio en su POM anula la dependencia), en lugar de implícito, como es el caso de los archivos jar administrados manualmente en el control de versiones, donde los archivos jar simplemente están presentes, sin nada que soporte si son la dependencia correcta o no.

Creo que Maven tiene una mala reputación porque la mayoría de los detractores no han observado la combinación de Maven + Hudson + Sonar . Si lo hubieran hecho, estarían preguntando "¿cómo empiezo"?

Algunas de mis cosas que me molestan con Maven:

• La definición XML es muy torpe y detallada. ¿Nunca han oído hablar de los atributos?

• En su configuración predeterminada, siempre rastrea la red en cada operación. Independientemente de si esto es útil para algo, parece extremadamente tonto necesitar acceso a Internet para "limpiar".

• De nuevo, de forma predeterminada, si no tengo cuidado de especificar los números de versión exactos, sacará las últimas actualizaciones de la red, independientemente de si estas versiones más recientes introducen errores de dependencia. En otras palabras, está a merced de la gestión de la dependencia de otras personas.

• La solución a todo este acceso a la red es apagarlo agregando la -oopción. ¡Pero debe recordar apagarlo si realmente desea actualizar las dependencias!

• Otra solución es instalar su propio servidor de "control de fuente" para las dependencias. Sorpresa: la mayoría de los proyectos ya tienen control de código fuente, ¡solo que funciona sin configuración adicional!

• Las compilaciones de Maven son increíblemente lentas. Jugar con las actualizaciones de la red alivia esto, pero las compilaciones de Maven siguen siendo lentas. Y horriblemente detallado.

• El complemento de Maven (M2Eclipse) se integra más mal con Eclipse. Eclipse se integra razonablemente sin problemas con el software de control de versiones y con Ant. La integración de Maven es muy torpe y fea en comparación. ¿Mencioné lento?

• Maven sigue teniendo errores. Los mensajes de error no son útiles. Demasiados desarrolladores están sufriendo esto.

Buena pregunta. Acabo de comenzar un gran proyecto en el trabajo y parte de proyectos anteriores fue introducir modularidad a nuestro código base.

Escuché cosas malas sobre Maven. De hecho, es todo lo que he oído al respecto. Miré introducirlo para resolver la pesadilla de dependencia que estamos experimentando actualmente. El problema que he visto con Maven es que es bastante rígido en su estructura, es decir, debe ajustarse al diseño de su proyecto para que funcione para usted.

Sé lo que la mayoría de la gente dirá: no tienes que ajustarte a la estructura. De hecho, eso es cierto, pero no lo sabrá hasta que haya superado la curva de aprendizaje inicial, momento en el que ha invertido demasiado tiempo para tirarlo todo.

La hormiga se usa mucho en estos días y me encanta. Teniendo eso en cuenta, me encontré con un administrador de dependencias poco conocido llamado Apache Ivy . Ivy se integra muy bien en Ant y es rápido y fácil obtener la configuración y el funcionamiento básicos de la recuperación de JAR. Otro beneficio de Ivy es que es muy poderoso pero bastante transparente; puede transferir compilaciones usando mecanismos como scp o ssh con bastante facilidad; Recuperación de dependencias en 'cadena' sobre sistemas de archivos o repositorios remotos (la compatibilidad con repositorios de Maven es una de sus características populares).

Dicho todo esto, me pareció muy frustrante usarlo al final: la documentación es abundante, pero está escrita en mal inglés, lo que puede aumentar la frustración al depurar o intentar resolver lo que salió mal.

Voy a volver a visitar Apache Ivy en algún momento durante este proyecto y espero que funcione correctamente. Una cosa que hizo fue permitirnos, como equipo, determinar de qué bibliotecas dependemos y obtener una lista documentada.

En última instancia, creo que todo se reduce a la forma en que trabaja como un individuo / equipo y lo que se necesita para resolver sus problemas de dependencia.

Puede encontrar útiles los siguientes recursos relacionados con Ivy:

• Comparación de Apache Ivy vs Maven 2
• Preguntas frecuentes sobre Apache Ivy
• Lista de funciones de Apache Ivy

Me encanta Maven, aumenta la productividad y estoy muy feliz de no usar más Ant (¡uf!)

Pero si pudiera cambiar las cosas sería:

1. Hacer pom.xml archivo sea menos detallado
2. Facilite la inclusión de archivos .jar que no sean del repositorio.

Hay muchas razones por las que a la gente no le gusta Maven, pero seamos realistas, son muy subjetivas . Maven hoy con algunos libros buenos (y gratuitos), mejor documentación, mayor conjunto de complementos y muchas construcciones de proyectos exitosas referenciales no es el mismo Maven que lo era hace uno o dos años.

Usar Maven en proyectos simples es muy fácil, con proyectos más grandes / complicados se necesita más conocimiento y una comprensión más profunda de la filosofía de Maven, tal vez a nivel de empresa un puesto para el gurú de Maven como administrador de red. La fuente principal de las declaraciones de odio de Maven es a menudo la ignorancia .

Otro inconveniente de Maven es la falta de flexibilidad como, por ejemplo, en Ant. Pero el recordador Maven tiene un conjunto de convenciones: apegarse a ellas parece ser difícil al principio, pero al final a menudo evita los problemas.

El éxito actual de Maven demuestra su valor. Por supuesto, nadie es perfecto y Maven tiene algunas desventajas y sus peculiaridades, pero en mi opinión, Maven influye lentamente en sus oponentes.

No diría que tiene una mala reputación, ya que tiene una repetición mixta. Si su proyecto sigue el paradigma de "convención sobre configuración" defendido por Maven, entonces puede sacarle mucho provecho. Si su proyecto no encaja bien en la visión del mundo de Maven, puede convertirse en una carga.

Con ese fin, si tiene control sobre el proyecto, entonces Maven puede ser el camino a seguir. Pero si no lo hace y el diseño lo determina alguien que no sea fanático de Maven, puede ser más problemático de lo que vale la pena. Los proyectos de Maven más felices son probablemente los que comenzaron como proyectos de Maven.

Para mí, el uso de maven vs ant para proyectos internos tiene tantos pros como contras. Sin embargo, para los proyectos de código abierto, creo que Maven ha tenido un gran impacto al hacer que muchos proyectos sean mucho más fáciles de construir. No fue hace mucho tiempo que tomó horas compilar el proyecto promedio OSS Java (basado en hormigas), tener que configurar un montón de variables, descargar proyectos dependientes, etc.

Puede hacer cualquier cosa con Maven que pueda hacer con Ant, pero cuando Ant no fomenta ningún estándar, Maven le sugiere encarecidamente que siga su estructura, o será más trabajo. Es cierto que algunas cosas son difíciles de configurar con Maven que serían fáciles de hacer con Ant, pero el resultado final es casi siempre algo que es más fácil de construir desde la perspectiva de las personas que solo quieren revisar un proyecto y listo.

Si va a apostar su negocio o trabajo en un proyecto de desarrollo, quiere tener el control de los cimientos, es decir, el sistema de construcción. Con Maven, no tienes el control. Es declarativo y opaco. Los desarrolladores de maven-framework no tienen idea de cómo construir un sistema transparente o intuitivo y esto queda claro en la salida del registro y la documentación.

La gestión de dependencias es muy tentadora, ya que podría aparecer en algún momento al inicio del proyecto, pero ten cuidado, está fundamentalmente roto y eventualmente te causará muchos dolores de cabeza. Cuando dos dependencias tienen dependencias transitorias incompatibles, se verá bloqueado por un nido de ratas de complejidad que romperá la construcción de todo su equipo y bloqueará el desarrollo durante días. El proceso de compilación con Maven también es notoriamente inconsistente para los diferentes desarrolladores de su equipo debido a los estados inconsistentes de sus repositorios locales. Dependiendo de cuándo un desarrollador creó su entorno o en qué otros proyectos están trabajando, obtendrán resultados diferentes. Descubrirá que está eliminando todo su repositorio local y que Maven vuelve a descargar los archivos jar con mucha más frecuencia que la primera configuración para una rama de desarrollo. Creo que OSGI es una iniciativa que intenta solucionar este problema fundamental. Yo diría que quizás si algo necesita ser tan complejo, la premisa fundamental es incorrecta.

He sido un usuario / víctima experto durante más de 5 años y debo decir que le ahorrará mucho más tiempo simplemente verificar sus dependencias en su repositorio de origen y escribir tareas hormiga agradables y simples. Con ant, sabes EXACTAMENTE lo que está haciendo tu sistema de compilación.

He experimentado muchas, muchas semanas de trabajo perdidas en varias empresas diferentes debido a problemas de Maven.

Recientemente intenté revivir un antiguo proyecto de GWT / Maven / Eclipse y después de 2 semanas de todo mi tiempo libre, todavía no puedo hacer que se compile de manera consistente. Es hora de reducir mis pérdidas y desarrollarme usando ant / eclipse me piensa ...

La respuesta corta: me ha resultado muy difícil mantener un sistema de compilación Maven y me gustaría cambiar a Gradle tan pronto como pueda.

He trabajado con Maven durante más de cuatro años. Me llamaría un experto en sistemas de construcción porque en las últimas (al menos) cinco empresas en las que he estado, he realizado renovaciones importantes en la infraestructura de construcción / implementación.

Algunas de las lecciones que he aprendido:

• La mayoría de los desarrolladores tienden a no dedicar mucho tiempo a pensar en construir sistemas; como resultado, la construcción se convierte en un espagueti de trucos, pero lo aprecian cuando ese desastre se limpia y se racionaliza.
• Al tratar con la complejidad, preferiría tener un sistema transparente que exponga la complejidad (como Ant) que uno que intente simplificar las cosas complejas imponiendo restricciones rígidas, como Maven. Piense en Linux frente a Windows.
• Maven tiene muchos agujeros en la funcionalidad que requieren soluciones bizantinas. Esto conduce a archivos POM que son incomprensibles e imposibles de mantener.
• Ant es súper flexible y comprensible, pero los archivos Ant también pueden volverse bastante grandes, porque son de muy bajo nivel.
• Para cualquier proyecto importante, los desarrolladores tienen que crear su propia estructura de construcción / implementación más allá de lo que proporciona la herramienta; la adecuación de la estructura al proyecto tiene mucho que ver con la facilidad de mantenimiento. Las mejores herramientas te ayudarán a crear una estructura y no te lucharán.

He investigado un poco a Gradle y parece que tiene el potencial de ser lo mejor de ambos mundos, lo que permite una combinación de descripción de compilación declarativa y de procedimiento.

Es más complicado que el lenguaje que usaste para escribir tu proyecto. Configurarlo correctamente es más difícil que la programación real.

He luchado para superar la mayoría / todos los aspectos negativos mencionados aquí, y objeciones similares de compañeros de equipo, y estoy de acuerdo con todos ellos. Pero me he mantenido firme y continuaré haciéndolo manteniéndome firme en el único objetivo que solo Maven (o quizás gradle) realmente cumple.

Si está optimizando para sus compañeros ( desarrolladores de código abierto ), ant / make / anything servirá. Si está brindando funcionalidad a usuarios que no son del mismo nivel , solo maven / gradle / etc.

Solo maven le permite lanzar un pequeño paquete de código fuente + poms (sin frascos de dependencia binarios / lib incrustados con nombres crípticos y sin información de dependencia) con un diseño de proyecto estándar bien documentado que cualquier IDE puede cargar por alguien que no haya absorbido las convenciones de diseño idiosincrásicas de los desarrolladores. Y hay un procedimiento de instalación con un solo botón (mvn install) que construye todo mientras adquiere las dependencias que faltan.

El resultado es una vía de acceso fácil que los usuarios pueden seguir para encontrar su camino hacia el código, donde los poms pueden señalarles la documentación relevante.

Aparte de ese requisito (indispensable), no me gusta Maven tanto como a nadie.