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

99

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.

Dan
fuente
29
Nunca escuché a nadie hablar mal de Maven. Descubrí que los proyectos son mucho más productivos con Maven que con Ant.
Taylor Leese
2
Estoy de acuerdo con Taylor. No he usado Maven, pero he escuchado a mucha gente hablar muy bien de él. Esta pregunta se parece mucho a FUD.
Matthew Flaschen
27
@Taylor, @Matthew, @victor: Me sorprende que no hayas visto algunas de las peroratas de Maven. Es una herramienta muy divisiva. Es una verdadera cosa de amarlo u odiarlo. Algunas personas aman la astucia del manejo de la dependencia y acusan a quienes no les gusta de no tenerla, y algunas personas solo ven los problemas que pueden ocurrir y ocurren con dependencias distribuidas complejas y deciden que no vale la pena molestarse.
Dan Dyer
8
Maven no respeta el principio KISS. Intente hacer cualquier otra cosa que no sea mvn clean install y tendrá problemas. Con hormiga puedes hacer lo que quieras sin ningún dolor.
TraderJoeChicago
4
Es solo una anécdota, pero pasar de Maven a Ant hizo que nuestros tiempos de construcción incrementales pasaran de ~ 15 segundos a más de 2 minutos. No encontrarás muchos fanáticos de Maven en nuestro equipo.
Peter Bratton

Respuestas:

141

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.

Kevin Peterson
fuente
134
Para aquellos que entienden a Maven, no es necesaria ninguna explicación. Para aquellos que no lo hacen, no hay explicación posible.
Apocalisp
35
Una de tus viñetas es falsa. -o - modo fuera de línea, así que no, no hace que su proceso de construcción dependa de su conexión de red.
MetroidFan2002
10
Estoy de acuerdo en el punto de todo o nada. He visto a muchas personas perder demasiado tiempo tratando de mantener la mitad de su cartera de proyectos en ant y la otra mitad en maven. Una vez que te comprometes, debes esforzarte para convertir cada parte de tu implementación.
sal
14
@Apocalisp: Entonces, en otras palabras, ¿las únicas personas que entienden Maven son las personas que lo escribieron?
Señor de poder
5
Maven es todo o nada. Eso no es cierto. Puede usar maven para la gestión de dependencias y nada más si lo desea. Todo lo que se necesita es un ejemplo práctico de cómo usar las tareas de hormiga de Maven para leer su archivo pom y generar una ruta de clase ANT que contenga todas sus dependencias.
Jherico
109
  • 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.
izb
fuente
45
++ Hace las cosas difíciles fáciles y las simples difíciles. ¡Es tan correcto!
Martin K.
8
"Promete mucho pero te traiciona como una amante hermosa y seductora pero emocionalmente fría y manipuladora". jajajaja ... eso suena mucho a ese fong maestro de "Balls of Fury"
cesar
8
Con respecto al punto 2: utiliza elementos casi siempre, atributos casi nunca, por lo que el XML es incluso más difícil de leer que el de Ant.
Carl Smotricz
4
+1 para la última viñeta. Nada hace que mi día sea mejor que encontrarme con una analogía asombrosa e hilarante que es tan cierta.
Adam
1
La documentación no es mala, es excelente.
HDave el
96

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.

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

Dominic Mitchell
fuente
2
No me importa particularmente el formato XML (Eclipse puede ocuparse de la mayoría de las partes tediosas) y las instrucciones de construcción para proyectos grandes suelen ser desagradables y complejas de todos modos. Por ejemplo, no se ha golpeado realmente la cabeza contra una pared de ladrillos hasta que ha intentado que GNU automake haga algo que no le interesa…
Donal Fellows
2
IntelliJ también tiene una excelente compatibilidad con Maven.
Steven Benitez
1
Oh, mira una respuesta sensata con detalles.
Tim O'Brien
80

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 :-)

KarlP
fuente
3
De hecho, estoy de acuerdo con algo de lo que dices, aunque creo que finalmente lo hice bien. Sin embargo, para obtener lo que desea, puede echar un vistazo a Ivy, todavía no lo probé, pero parece llevar la administración de dependencias a un entorno Ant más estructurado.
Newtopian
5
Entonces, ¿encontraste alguna buena alternativa a Maven?
Thilo
4
La integración de Eclipse sigue siendo terrible. A pesar de tener complementos actualizados, hay tareas maven controladas por complementos que fallan con oscuros mensajes de error. Los colegas me dicen que me vaya a un shell de comandos y ejecute el mismo comando ... entonces misteriosamente funciona. Eclipse es un entorno maduro, el complemento maven se queda muy atrás.
Carl Smotricz
2
Existe una diferencia fundamental en cómo Maven y Eclipse definen qué es un proyecto. En Maven, un proyecto es más o menos una forma conveniente de organizar el código fuente. Eclipse se diseñó inicialmente para que pudieras trabajar en uno o varios proyectos más o menos no relacionados al mismo tiempo. Los requisitos posteriores (no siempre sólidos) conducen al abuso de IBM de proyectos como "módulos" que Eclipse realmente maneja bastante mal. Para hacer converger las definiciones, en muchos casos, los proyectos de maven probablemente deberían mapearse para eclipsar las carpetas de origen. Sin embargo, como maven es una mierda, ¿para qué molestarse?
KarlP
3
¡Oye! Lamento el hecho de que la próxima vez que tenga una edad óptima sea 29, y la próxima edad perfecta del cubo sea 64, y mi última edad penteract perfecta sea 32 ... pero no defiendo activamente a Maven.
cwallenpoole
46

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.

Cuga
fuente
6
Esto puede ser algo cierto, pero he descubierto que usar la integración de Maven con Eclipse realmente ayuda a recortar la curva de aprendizaje para la gente. m2eclipse.codehaus.org
Taylor Leese
2
@Taylor, tuve muchos problemas con el complemento, especialmente si usas alguna otra versión de Eclipse o el cielo no lo permita RAD. Sin embargo, creo que está llegando allí ...
Dan
Solo lo he usado con Eclipse 3.3, 3.4 y el estudio de desarrollo de JBoss y estuve de acuerdo en que hay algunas molestias menores (como que el editor de POM no funciona bien) pero no he tenido ningún problema importante.
Taylor Leese
10
No es la curva de aprendizaje lo que me molesta. Realmente no es tan difícil de entender. Mi problema es que para proyectos grandes (comerciales), obtienes mucho menos valor que el esfuerzo invertido. Bien, sus proyectos se construyen. Genial, pero el costo de un año de trabajo invertido, constantes fallas de construcción debido a factores externos, compilaciones de 10 minutos en lugar de 5 segundos y un espacio de trabajo de eclipse feo, simplemente no vale la pena. Además, por el mismo costo, puede contratar más o menos a un tipo que constantemente está construyendo el maletero manualmente.
KarlP
8
@Karlp - bueno, todavía no lo entiendes completamente ... 1.) "fallas debido a factores externos" - debes crear un repositorio de proyectos en el que mantengas todas tus dependencias y en el que controles las versiones. 2.) "compilaciones de 10 minutos en lugar de 5 segundos", tal vez para la instalación inicial de maven y la primera compilación, maven descarga todas las dependencias que necesita más su proyecto, pero las compilaciones regulares que está haciendo para intentar compilar su propio código no deberían estar descargando - ver 1 - también, modo fuera de línea. 3.) "espacio de trabajo de eclipse feo" - maven funciona en todos los IDE principales (NB, IntelliJ) y desde la línea de comandos.
Nate
24

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

Apocalipsis
fuente
3
¡Deberíamos producirlo en masa y venderlo a todos los villanos para obtener una gran ganancia!
Joachim Sauer
7
¡No! Maven no se puede utilizar con fines de lucro. Solo se puede usar para el mal.
Apocalisp
18

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.

Sasha O
fuente
3
Ant no compite con Maven. Ivy no compite con Maven (compite con las tareas de Maven Ant). Maven es más que una herramienta de construcción + gestión de dependencias. Período.
Pascal Thivent
18

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

sal
fuente
16

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.

Steve B.
fuente
14

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.

Guillaume
fuente
12

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.

Jherico
fuente
11

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.

Dom
fuente
4
Estoy de acuerdo con ésto. Creo que se exagera el valor de la gestión de la dependencia. Seguro que está limpio cuando todo funciona, pero introduce varios puntos de falla potenciales (sin mencionar los posibles agujeros de seguridad). Puede configurar su propio servidor de repositorio para mitigar un poco los problemas y bloquear los números de versión para evitar actualizaciones inesperadas, pero todavía prefiero agregar las dependencias al control de versiones, ya que no cambian con tanta frecuencia y garantiza una compilación repetible. .
Dan Dyer
8

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.

Zac Thompson
fuente
2
Zac, sabes que me preguntaba si querías aprender más sobre Nexus Professional. :-)
Tim O'Brien
7

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.

Paul Sonier
fuente
2
Estoy de acuerdo en que inicialmente la gente puede perder el control que tenían con Ant, pero una vez que un proyecto llega a aceptar las convenciones que impone Maven, realmente verán una ganancia en productividad de él.
Taylor Leese
5
No es cierto, Maven le permite cambiar la estructura del proyecto, solo sugiere una estructura que se usa ampliamente.
adrian.tarau
3
No creo que esto sea cierto. La mayoría de las quejas sobre Maven se refieren a las formas en que puede fallar, lo lento que es o la documentación. Realmente nunca he notado que nadie se queje de la estructura.
Dan Dyer
@Dan Dyer: Yo apoyo eso. La estructura es en realidad una de las pocas cosas buenas que hace Maven. Es todo lo demás lo que hace a Maven tan horrible.
Carl Smotricz
6

Demasiada magia.

Adam Jaskiewicz
fuente
3
Sea más específico: ¿qué tiene de mágico que no esté documentado?
whaley
4
Es mágico tan pronto como tienes que buscar en la web durante 2 horas para descubrir por qué algo no funciona como se esperaba. Si desea un ejemplo específico: ¿por qué no se ejecuta mi complemento? Tienes 2 horas.
Damien B
En realidad, cada vez que hago algo que no implica buscar en la web durante 2 horas, empiezo a sospechar que estoy usando la herramienta incorrecta para el trabajo o que he entendido mal / subestimado gravemente los requisitos.
Doug Moscrop
6

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.).

Pascal Thivent
fuente
5

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.
Robert Munteanu
fuente
+1 para vincular a una implementación de repositorio alternativa.
Donal Fellows
5

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.

vk
fuente
Estoy de acuerdo en que la idea es mejor que la ejecución. No es una tarea pequeña que eligieron para su defensa, pero a menudo me pregunto si las cosas no podrían haberse hecho de una manera más sencilla.
Eelco
5

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.

mdma
fuente
5

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"?

Zac Thompson
fuente
+1 por mencionar a Sonar.
Becarios Donal
1
Lo he visto. Todavía no hay ninguna razón para usar Maven. Hudson y Sonar no necesitan maven.
rk2010
5

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.

Carl Smotricz
fuente
2
Nunca he tenido a Maven sacar lo último de una dependencia a menos que esté usando una dependencia SNAPSHOT o agregue una nueva característica que requiera algo. Si solicito la versión 1.2.3 y tengo 1.2.3 en mi repositorio local, no obtengo 1.2.3 nuevamente.
Mike Cornell
1
Tú controlas tus dependencias directas, sí. ¿Quién controla las dependencias de sus dependencias?
Carl Smotricz
Para su primer punto, acerca de los atributos, que se supone que se abordará en el próximo, (como por MUCHO tiempo, lo admitiré) Maven 3.
mezmo
@mezmo: Sería muy bienvenido. Gracias por la info!
Carl Smotricz
4

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:

Alex
fuente
1
Ivy no compite con Maven (tal vez con Maven Ant Tasks, pero no con Maven).
Pascal Thivent
1
Ivy no compite con Maven Ant Tasks, compite con la gestión de dependencias de Maven.
Damien B
@atc ¡¡Esto estaba bien !! : "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ás hasta que hayas superado la curva de aprendizaje inicial, momento en el que has invertido demasiado tiempo para ir y tirarlo todo ".
rk2010
4

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.
flybywire
fuente
1
Creo que los usuarios de Maven estarían mejor si los IDE permitieran importar archivos jar faltantes o de terceros en los repositorios locales. ¿Qué tan difícil sería tener un cuadro de diálogo "elegir el tarro, hacer clic en importar"?
sal
@sal Supongo que Maven no quiere promover una práctica que rompa la portabilidad.
Pascal Thivent
1
Considero que el hecho de que sea difícil agregar frascos de lugares aleatorios es una fortaleza. Si está en un entorno de equipo y necesita usar un jar extraño, debería implementar ese jar en el repositorio de expertos de su equipo. De esa manera, el resto del equipo y sus servidores de CI realizarán la misma compilación. Todo el mundo ejecuta la misma construcción es una base de la filosofía maven.
tunaranch
+1 para lo del tarro. Traer tus propios frascos prediseñados en una construcción (por cualquier motivo) es un dolor innecesario.
Thorbjørn Ravn Andersen
@tunaranch personalmente, me gusta que las cosas estén en Maven Central o estén (jarras y todo) en lo que se está comprobando desde el control de versiones. Básicamente, quiero poder llevar mi repositorio git en una unidad USB, comprobarlo, ejecutar "mvn clean install", ir a almorzar y estar en funcionamiento.
Thorbjørn Ravn Andersen
4

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.

cetnar
fuente
@Pascal. En caso de problemas con Maven, hay un stackoverflow y usted aquí :)
cetnar
3

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.

Glenn
fuente
"No diría que tiene una mala reputación tanto como tiene una repetición mixta". Yo diría que probablemente sea más preciso, solo las opiniones negativas tienden a sobresalir más.
Dan
Estoy de acuerdo en que portar un proyecto a maven aumenta la dificultad experimentalmente en relación con el tamaño del proyecto (proyecto más grande para importar = importación más difícil). usar maven para iniciar un proyecto es el mejor enfoque para usar maven. De lo contrario, puede que no valga la pena el esfuerzo.
Luigimax
3

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.

Eelco
fuente
3

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 ...

Alex Worden
fuente
3

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.

bobtins
fuente
3

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.

jpswain
fuente
3

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.

Bradjcox
fuente