java - que - ¿Por qué tan poca gente usa Maven? ¿Hay herramientas alternativas?

mvn clean install que es (24)

Estaba en estado de shock: el 67% de los desarrolladores no usan Maven. ¿Por qué?

Todo se ve brillante cuando estás aprendiendo algo nuevo, y con la introducción correcta, Maven (o cualquier herramienta para el caso) se verá genial. Cuando tienes algo que ya existe, y posiblemente imperfecto, es decir, un proyecto que no es Maven, tratar de clavarle el claxon a Maven es un PITA.

¿Hay algunas herramientas alternativas que facilitan la administración de proyectos?

Google lo dice. Hormiga, Gradle, Gant, Ivy, Rake, SBT. Personalmente, estoy a favor de Gradle y Gant por sobre cualquier otra cosa. SBT puede ser un cerdo, pero una vez que lo tienes funcionando, es dulce. Y usaría Ant sobre Maven para cualquier proyecto nuevo o existente.

No me malinterpreten, he usado Maven, y puedo dominarlo. El problema es que realmente encasilla cosas con su arquitectura plug-in. Intente hacer algo de inmediato y se convertirá en una tarea complicada.

Para mí, se sorprendió cuando la programación experimentada habla sobre las dificultades de Maven, cuando vi a Ant en algún proyecto, Maven me mostró un milagro

Tal vez esos programadores experimentados están en algo. OMI, para entender a Maven, primero tienes que entender a Ant, y lo que Maven intentó o intentó resolver.

Hormiga

A Ant se le da la mala reputación porque la mayoría de las personas son programadores deshonestos, y toman sus malas prácticas cuando crean sus sistemas de compilación Ant.

Los malos programadores hacen lo siguiente:

o simplifican demasiado las cosas y crean sistemas de compilación que no pueden hacer frente al cambio en el proyecto (cualquier sistema complejo de la vida real experimenta cambios)

o complican demasiado las cosas al tener un bosque negro, un ejército oscuro de construcciones de hormigas esparcidas por todo el lugar, sin ningún pensamiento coherente detrás de ellos. Por lo general, esto es el resultado de esfuerzos equivocados en el desacoplamiento, que en realidad se convierte en lo que yo llamo súper acoplamiento distribuido : todo depende de todo lo demás para funcionar bien sin tener ninguna garantía de que lo hagan.

La hormiga sigue bastante un modelo llamado GIGO : Garbage In, Garbage Out. Debe tener una previsión significativa al crear sus scripts Ant.

Esto no es un problema para un buen desarrollador. Lamentablemente, para la gran cantidad de desarrolladores malos que existen, crean estas monstruosidades y culpan a la herramienta. Es como poner tu trasero en una parrilla y culparlo por quemarte.

Maven

Entra a Maven. Intenta resolver el monstruo de la súper complejidad proporcionando esqueletos de proyectos y construcción de andamios. Lo que Maven llama arquetipos. Invoca a Maven para que cree un nuevo proyecto usando el arquetipo maven-archetype-webapp , y listo, construye un andamio de proyecto completo para usted, incluida la estructura de directorios, los descriptores de implementación y lo que no.

Pero, ¿qué sucede cuando tienes un sistema existente que no necesariamente cumple con el arquetipo? ¿Qué sucede si quieres o necesitas un diseño diferente?

Hay soluciones (es decir, crea tu propio arquetipo), pero las cosas ya no se vuelven tan simples. Luego está todo el tema de un repositorio. Muchas veces puede simplemente usar los repositorios predeterminados y extraer lo que necesita sobre el cable.

En otras ocasiones, simplemente no puede y luego entramos en los dominios de la logística. ¿Dónde colocas tu repositorio? ¿Tiene uno para todo el negocio, o diferentes proyectos tienen los suyos (debido a requisitos legales o geográficos)? ¿Versión los contenidos de su repositorio, o repositorios?

En caso afirmativo, ¿qué sucede cuando se requiere legalmente / contractualmente que use un repositorio de control de origen como ClearCase, donde tiene que verificar explícitamente las cosas antes de un cambio? Cosas logísticas innatas que ni siquiera deberían entrar en escena y la mente de los desarrolladores comienza a infiltrarse.

Hay razones prácticas (y estúpidas) para preferir Ant sobre Maven y viceversa. Da la casualidad de que la división es de 1/3 a favor de Maven y 2/3 a favor de Ant. La división se asemeja mucho a la relación que he visto entre los nuevos proyectos y los existentes.

Una razón importante para evitar (o al menos tener dudas objetivas) Maven es con respecto a su documentación. Ha mejorado un poco, pero solía apestar. Eso conduce a un problema logístico. Si soy un director de recursos humanos, debo considerar algunas de las herramientas para tener una audiencia más amplia e informada.

Simplemente sucede que hay muchos más desarrolladores de Ant-aware (buenos y malos) que los desarrolladores de Maven (buenos y malos). Esto es algo que consideraría seriamente.

De nuevo, he trabajado en proyectos de Maven, y no tengo problemas para usarlo en arquetipos convencionales y personalizados. Yo prefiero no hacerlo. Quizás mis gafas están coloreadas por haber usado Ant mucho más tiempo (el doble de años en realidad).

Dicho esto, usaría Gradle para un nuevo sistema (o reescribiría un sistema de compilación Ant o Maven si tuviera la autoridad y los desarrolladores a mi alrededor fueran medio competentes como mínimo).

Es simplemente un sistema de construcción superior en comparación con Ant y Maven.

Soy nuevo en Java, y cuando comencé mi desarrollo, mis amigos recomendaron Maven para la gestión de proyectos. Casi de inmediato me di cuenta de que es una herramienta indispensable, y en ese momento estaba pensando que todos los programadores lo usan. Pero cuando veo estadísticas en el sitio de NetBeans, estaba en estado de shock: el 67% de los desarrolladores no usan Maven. ¿Por qué? ¿Hay algunas herramientas alternativas que facilitan la administración de proyectos?

ACTUALIZAR

Estoy de acuerdo con feicipet en 100%.

IDE independientes es realmente bueno. Esto fue probado en mi propia experiencia. Primero, nuestro equipo usó el Eclipse, luego decidimos cambiar a NetBeans, las personas que nos ayudan con el proyecto usando IDEA. Y no importa porque el proyecto se puede ejecutar incluso con la consola :)
Proyecto bien estructurado y limpio. Creo que la convención de estructura de Maven es muy útil, porque las pruebas y el código principal están separados.
Gestión de proyectos. Maven no es solo una herramienta de compilación , sino que le da la capacidad de configurar su entorno, ejecutar pruebas unitarias y crear informes.

Para mí, se sorprendió cuando la programación experimentada habla sobre las dificultades de Maven, cuando vi a Ant en algún proyecto, Maven me mostró un milagro. Y todos los comentarios sobre la complejidad de la transición de Ant son extraños. Esta es una lógica diferente, ¿qué esperas?

Hay algunos problemas con la documentación, esto es realmente malo. Pero creo que esta situación cambiará para mejor

Como ya se dijo, hay una gran barrera de entrada. También hay toneladas de proyectos más antiguos que ya tienen herramientas / scripts de compilación bien establecidos; en la mayoría de los casos, no tiene sentido reemplazar algo que ya funciona con maven.

La falta de / documentación dispersa tampoco ayuda - el único tutorial realmente bueno para maven es un libro completo escrito por sonatype ... y eso es bastante pedirle a alguien que lea y luego aprender cómo funcionan los complementos para el único propósito de construir / administrar un pom.xml para definir cómo se construye / administra un proyecto.

Dicho esto, maven es una gran herramienta (incluso si es demasiado compleja para su propio beneficio).

Creo que Maven sufre una barrera de entrada relativamente alta en comparación con herramientas como Ant. Las dificultades con versiones anteriores y la complejidad de 2.0 me han mantenido alejado. No es 100% necesario, especialmente si tienes un buen IDE.

Después de migrar demasiados proyectos a maven (que van desde java puro hasta javascript puro y proyectos xslt), creo que los pros: los contras de usar maven son 50:50. Los contras más importantes son:

es increíblemente lento
disminuye significativamente el ciclo desarrollo-despliegue-prueba
tiene una estructura de proyecto ridícula. A menos que desarrolles un proyecto Java puro, la estructura no tiene sentido.
el proceso de compilación se especifica de forma declarativa. ¿Qué es más claro: <copy from="" to=""/> o registrando el plugin mvn y especifica toneladas de propiedades?
mvn los autores son propensos a la crítica constructiva

Estoy de acuerdo, no entiendo por qué cualquiera que haya usado Maven optaría por otras herramientas.

Creo que la disparidad se reduce a imperativo vs. declarativo. Los programadores comienzan a aprender la programación imperativa, es decir, a Ant, existe una zona de comodidad que se mantiene en un lenguaje imperativo, aunque se necesitan archivos de script más largos, uno siente que siempre puede cambiarlo. Maven es declarativo, tienes que confiar en que las cosas se declaran correctamente, y cuando no funcionan como esperas, ¿qué haces? Esto junto con complementos mal documentados no ayuda. Es por eso que estas otras herramientas que tienen las características de Maven, pero usan un estilo imperativo son populares.

Haría el mismo argumento de Wicket / Tapestry sobre JSP, ¿por qué en el mundo alguien usaría el estilo de script JSP cuando se puede declarar el uso de los componentes? Vuelve a la zona de confort. Creo que declarative se volverá más popular y Maven es una de esas tecnologías que está empujando el envolvente, pero a medida que obtengamos computadoras masivamente escalables, los lenguajes y técnicas declarativos se convertirán en una zona de mayor comodidad y tarifa estándar.

Hay muchas alternativas, en la comunidad de Java y Ruby. Para una visión general, mira esta imagen

IMO Maven es una máquina Rube Goldberg sobre-diseñada, o en palabras de Graeme Rocher (líder del proyecto Grails ), "el EJB2 de las herramientas de construcción" .

Creo que los objetivos del proyecto Maven son muy valiosos. ¿Convención sobre configuración? ¡Estupendo! Resolución de dependencia automática? ¡Súper! Pero lamentablemente la práctica es muy diferente de la teoría. En mi experiencia, la introducción de Maven a proyectos que previamente se construyeron con Ant ha creado invariablemente más problemas de los que resolvió. En un caso, Maven comenzó a ocupar tanto tiempo que eventualmente volvimos a migrar a Ant.

Creo que Maven podría valer la pena si estás construyendo una gran cantidad de proyectos que todos dependen el uno del otro, y el desarrollo está ampliamente distribuido. Pero si está compilando una sola aplicación y solo quiere hacer algo tan simple como "compilar una GUERRA a partir de las cosas en estos directorios", entonces correría una milla desde Maven.

Un problema que he encontrado con Maven es que en realidad es bastante inflexible si necesitas hacer algo que vaya en contra de las convenciones de Maven. Aunque puede anular estas convenciones en algunos casos triviales (por ejemplo, cambiar el nombre de la carpeta de origen de src a source ), algunas de sus convenciones parecen estar escritas en piedra, por ejemplo, un artefacto por proyecto. Tomemos el ejemplo de un proyecto web Maven cuyo artefacto es un archivo .war. Ahora imagine que nos gustaría incluir el número de revisión SVN actual en el nombre de archivo .war. Esto no parece ser particularmente difícil de lograr, pero a menos que pueda encontrar un complemento que ya lo haga, probablemente tenga que escribir su propio complemento para lograrlo, lo cual no es una tarea trivial, ya que requiere a comprender el modelo de objetivos y ciclos de vida de Maven.

Para responder la segunda parte de su pregunta sobre alternativas: No lo he usado personalmente, pero he escuchado cosas muy buenas sobre Gradle . Varios proyectos JVM de alto perfil como Spring e Hibernate que se construyeron previamente con Maven han cambiado recientemente a Gradle.

Maven definitivamente puede poner un calambre en su estilo. Cambié una generación de hormigas a maven porque tenía una gran cantidad de proyectos con interdependencias. Tengo la construcción en marcha, pero todavía no siento que tengo la cabeza alrededor de la bestia.

Mucho del problema se reduce a la documentación. La guía canónica es a menudo una publicación en el foro o una respuesta a un problema totalmente diferente que acaba de suceder.

Como esta guía para usar la carga: Comencé el proceso externo durante las pruebas de integración en maven , que no encontré en el sitio web del plugin maven-cargo, sino simplemente porque estaba trolling a través de .

Pero cuando observas ese mojo, y luego la página de carga, ¿es realmente comprensible para el desarrollador promedio (léeme)?

Tal vez Maven es como el capitalismo, es el peor excepto por todo lo demás.

Maven es una gran herramienta, los conceptos y el mundo de trabajo que ofrece son un gran salto adelante, no tan lejos, cuando simplemente esquivamos el código de cinta para crear software (ahora estoy buceando en una aplicación Deplhi heredada con más de 1M de LOC). . ho el dolor ... cuánto echo de menos a Maven)

Dicho esto ... Macho IMHO todavía está en su infancia, la documentación, aunque mucho mejor que antes, todavía es escasa y difícil de conseguir. El control de complementos todavía tiene algunas fallas, ya que puede ser difícil tener un control completo sobre su entorno de compilación. También el comportamiento del sistema aún cambia mucho de una versión a la siguiente, por lo que es difícil garantizar que las compilaciones sean estables a tiempo.

Así que puedo ver por qué las personas se alejarían de Maven viniendo de Ant por ejemplo. Maven, para un usuario de Ant, tiene muchas propiedades mágicas y un comportamiento que crea un incómodo aura de incertidumbre que no concuerda con la típica paranoia de maestro de construcción que obtenemos cuando comenzamos a implementar aplicaciones para el cliente y queremos una versión estable.

A pesar de todo esto, están en el camino correcto y la lenta penetración que ve es en realidad una "cosa buena" porque mantendrá el crecimiento del sistema dentro de rabieces manejables para que los problemas se resuelvan a tiempo.

Aprender Ant como un sistema de compilación puede ser un mejor primer paso, ya que lo ayudará a comprender los requisitos y las dificultades en una compilación. Además, si Maven no está actuando como lo desea, siempre puede volver a Ant y luego integrarse en la imagen más grande.

Los objetivos que Maven intenta lograr son encomiables y el camino es muy complejo. Pero si permites que tu mente extrapole cómo sería el mundo en la era de la información, rápidamente te darás cuenta de que lidiar manualmente con las dependencias para nombrar solo un aspecto de Maven pronto me resultará imposible.

Si Maven falla por falta de adopción, pero deja solo la idea de la convención sobre la configuración, ya habrá logrado algo grandioso ...

... Pero es mucho más que eso.

Larga historia corta :

Las herramientas de Maven son esenciales, pero fíjate bien si te morderá a medida que madure
Mantenga una diversidad saludable en su mecanismo de compilación para que siempre pueda recurrir a otros métodos más simples si Maven falla esa necesidad en particular.
Suscríbete al grupo de noticias y lee mucho de la experiencia ajena, escribir documentos lleva tiempo y casi siempre está desactualizado, especialmente en una herramienta tan innovadora como maven.
Sobrevivir a sus frustraciones tempranas, sus esfuerzos lo recompensarán a tiempo.

Mi 2 centavo

Me gusta Maven y lo uso casi exclusivamente en mi compañía. Pero justificaría mis razones para hacerlo:

Dirijo un equipo de desarrolladores y necesitamos estructura. Necesito que la mayoría de mis desarrolladores sigan un cierto conjunto de convenciones hasta diseños de proyectos. Esto es para facilitar el traspaso cuando ocurre la atrición.
Los arquetipos de Maven son una gran bendición en este sentido. Los seniors simplemente crearían arquetipos específicos para ciertas plantillas de proyectos en las que todos los desarrolladores solo basan sus proyectos. Hay un genérico realmente simple para aquellos casos en los que no logramos atender. Comprobar un diseño basado en antis desde SVN es menos intuitivo a este respecto, ya que el desarrollador aún tendrá que eliminar los metadatos originales .svn una vez que se haya verificado.
Maven nos ayuda a permanecer IDE-agnóstico. No quiero basar ninguna de mis políticas de contratación en qué IDE prefiere usar el desarrollador. Al menos 2 grandes IDEs (Eclipse y NetBeans) ya tienen una buena integración con Maven, de modo que un archivo pom.xml ya es la definición de un proyecto IDE. Puedo decirle a cualquier desarrollador nuevo que puede usar cualquier IDE que prefiera, siempre y cuando el sistema de compilación esté basado en Maven.
Descubrí que el proceso de arranque del desarrollo para recoger cosas a mitad de camino se redujo drásticamente cuando cambié a Maven. Los nuevos desarrolladores, incluso aquellos que no están familiarizados con el proyecto en cuestión, pudieron al menos compilar, empacar y desplegar en media hora después de informarles sobre el proyecto. El personal de soporte (que generalmente no es tan hábil técnicamente) fue capaz de concentrarse en la resolución de problemas y no se preocupó por la construcción del proyecto, lo cual es una irritación innecesaria.

Con todo, Maven se adapta perfectamente a mis necesidades. Estoy de acuerdo hasta cierto punto con que un desarrollador independiente que tenga su propio flujo de trabajo y prácticas de gestión de proyectos no obtenga muchos beneficios, pero ninguno de nosotros trabajamos en un vacío por nuestra cuenta.

Muchas de las quejas de Maven que he encontrado se enumeran y responden en esta entrada del blog . Mi experiencia es que los desarrolladores de Java están acostumbrados a tener un control total sobre sus proyectos. Muchas de las razones por las que están en contra de Maven son, básicamente, "no es hormiga" o no puedo hacer X como puedo en la hormiga ".

Ciertamente hay algunas quejas válidas. La documentación a menudo es lamentable, la curva de aprendizaje puede ser pronunciada y la configuración es detallada. Debido a la gran cantidad de convenciones involucradas, cuando algo va mal, puede ser muy difícil determinar si es tu culpa o una característica / error en un complemento.

Entonces, teniendo en cuenta los aspectos negativos, es comprensible que las personas no se sientan dispuestas a invertir tiempo y esfuerzo en una herramienta de construcción cuando puedes ir con lo que sabes (ant / make / whatever) y seguir "haciendo el trabajo", después de todo tu a los clientes no les importa qué tan sexy sea su proceso de construcción.

Para una herramienta alternativa, ofrezco Gradle . Se basa en Ant y Maven y es compatible con todos los objetivos estándar (compilación, pruebas unitarias, etc.). El beneficio clave es que la configuración está en Groovy, lo que hace que los archivos sean fluidos y concisos. (Dicho esto, uno tendrá que aprender Groovy, hasta cierto punto).

El punto clave es que es una falsa dicotomía enfrentar a Ant-Ivy versus Maven, como muchos lo hacen. He escrito sobre esto here . (Tenga en cuenta que desde la publicación del blog, Gradle ha reemplazado a Gant como una herramienta general de compilación).

Solo tengo una cosa que decir: demasiadas quejas ... Tal vez no sea la herramienta perfecta, pero definitivamente hay muchas quejas ... De hecho, agrega cierta complejidad y se puede llegar a algunos obstáculos (no encontramos nada irresoluble) pero al final verás los beneficios.

Leí hace unas semanas sobre un chico que pasó (esto es lo que dice) más de 500 horas tratando de usar Maven ... Podrías escribir algunos complementos de Maven y construir tu aplicación en 500 horas.

Y por cierto, es de código abierto y, si encuentra un problema, informe o solucione el problema

si es realmente un problema, estoy seguro de que se solucionará.
si es una buena sugerencia, estoy seguro de que se tendrá en cuenta.

PD. No soy parte del equipo de Maven, solo un usuario habitual, nada más.

Trabajé brevemente en una empresa alrededor de 2005 que tenía una construcción Ant con aproximadamente 80 subproyectos. Reconocieron lo importante que era para un equipo administrar las pruebas y las versiones, por lo que tenía que haber una compilación reproducible, pero las dependencias de los módulos eran complejas y difíciles de visualizar para cualquiera sin herramientas gráficas.

Lo que hicieron fue bastante novedoso por el momento. Reconociendo que podían verificar los metadatos de Eclipse y los metadatos (como XML) era fácil de analizar, escribieron un complemento Ant para leer los archivos .classpath y componer las dependencias para la compilación formal de esa manera.

Curiosamente, nadie en la compañía sabía cómo funcionaba esto, solo sabían que si alguien arruinaba su versión de Eclipse y lo registraba, todo se rompería. Los chicos en la gestión de lanzamientos sabían cómo se generaban y empaquetaban los artefactos, los desarrolladores entendieron que la construcción era una gran caja negra que podía ajustarse en Eclipse, pero ninguno de los dos entendía el dominio del otro.

Lo curioso es que tenían MacGyvered Maven juntos y ni siquiera se daban cuenta.

Esta historia es importante por algunas razones. En primer lugar, para las tiendas que no conocen a Maven y que nunca van a agrandarse, Maven podría ser excesivo. Diría que las construcciones que están por encima de algunas docenas de módulos se vuelven difíciles sin Maven. En segundo lugar, aunque Maven podría parecer "mal documentado" y "hacerse cargo de la compilación", el hecho es que hay más documentación de la que existe para el 98% de las compilaciones de procedimientos personalizados creadas localmente. Con una versión Maven, cualquier persona que conozca a Maven puede ser contratada para trabajar en ella, lo cual es bueno o malo dependiendo de su perspectiva de la seguridad laboral sintética a través del sacerdocio interno. Por último, si bien muchos desarrolladores estelares usan Eclipse, los que no lo hacen no van a comenzar solo porque usted tiene un trabajo para ellos. A menudo van a ir a otro lugar.

Maven definitivamente requiere una inversión para aprender, pero resulta que no es más inversión que si todas las otras cosas (como repositorios y documentación) se toman en cuenta en una construcción masiva. Lo que más importa en este día y edad es la interoperabilidad con el Repositorio Central de Maven, y que eventualmente requiere POM. Es posible sintetizar POM con herramientas como SBT y Gradle, pero si alguien en el grupo necesita saber cómo depurarlas para publicarlas, el hecho de no aprender Maven es algo discutible.

Algún día Maven Central no será tan importante, pero hasta entonces ...

En cualquier caso, hay muchas razones a favor y en contra de Maven. Es la construcción de facto que existe, de lo contrario, las otras herramientas de construcción no se basarían en Maven Central de la forma en que lo hacen.

Trabajo en grandes proyectos de desarrollo con múltiples equipos en diferentes geografías. He corrido un par de veces y ahora, después de unos pocos días para sentirme totalmente frustrado cada vez que lo intento, he tenido que lanzar las manos al aire y rendirme. Puedo usar macros Ant con dependencias registradas en mi repositorio fuente.

Claro que preferiría usar maven, pero es muy difícil despegar.

La calculadora fue un gran avance con respecto a la regla de cálculo porque era más fácil de usar (además de poder resolver más problemas). Aunque maven puede resolver algunos problemas, también crea problemas por sí mismo (lo que hace que las tareas simples sean mucho más difíciles, especialmente las más difíciles de depurar y solucionar).

La curva de aprendizaje es demasiado empinada para el desarrollador promedio. A menos que tengas un experto en cohetes-científico (y evangelista) en tu proyecto, olvídalo. El desarrollador promedio no puede invertir el tiempo para aprender a sí mismo. Alguien en el equipo necesita ser el experto para que el resto pueda desarrollar software.

EBuild is a modern alternative to Maven.

We use it for all our development. Es muy bueno. However, I must qualify that by stating that my brother wrote it.

It simply manages / builds all your projects for you. You check out a project, and ebuild handles the rest. It fetches all dependencies and builds them. When you are ready to release, the release script then produces the build for you.

Currently it is geared to being used with Eclipse and only works with SVN (designed with the intention to support other SCMs such as GIT etc).

I believe Maven can do almost everything that Ant can do, still if your code is coupled much with Ant then you can still call Ant from within Maven.

I only problem I see is that documentation is not that good, but will improve over time.

Espero que esto ayude. Brief about Maven, Comparison between Ant & Maven

I think maven is like object oriented programming in that it is hard to master after years of structured programming but it has strong benefits over imperative tools like Ant. I love maven even though I must admit it took me around 3 days to learn it to a sub-comfortable level and implement it with existing eclipse wtp projects with dependent projects and lots of external jars, and with eclipse and m2e. Once learned and implemented, it is way easier now and much more cleaner and organized.

I think that Maven has been massively adopted and I have to disagree with the statement that "so few people use Maven". If one googles for MVN Respository, or visit the SpringSource.org site one finds how many useful libraries and projects are built with Maven.

Maven has a pretty stiff learning curve. Its upside down from most build control systems. The majority pif those are descend from Make and are, to one degree or another, change sensitive script engines. You tell it what the build operations are in a scripted fashion.

Maven, on the other hand, works off a standard build model that you match your code to.

Its quite powerful but NOT easy to use. Its best feature is remote repositories, and this is coming back into the other types of build tools now.

Maven makes Project Managers and other (non-developer) human interferences obsolete. ¿Entonces por qué no? Ok there are some issues and some shortcomings, but for now only ivy gets close enough. Upcoming releases should include a Functional Analysis generation Mojo or even extended integration of continuos build platforms and system set-up Mojo''s. Personally I'' m really fond of the grails way of handling project dependencies and plugins since a while now. Just love it.

My issue with Maven is that one of the main things it does is not a best practice. Maven will go out and download the newest version of any dependency you have. While that sounds good, it is a bad practice. I want the dependencies for my project in my project because I don''t want each developer to have difference versions of jar files and I definitely don''t want untested dependencies to be used when deploying to prod.

If maven had an easy way to allow me to package the dependencies with the project and not download them for me, I''d use it. For now, I only have it installed because some code I deal with forces me to use it.

Yes, I know that it is possible put a dependency repository in my project and make my project use it, but that is a huge pain. I just want a lib folder in my project and tell maven that those are the jars I''m using. período. I''d much rather write an ant build.xml file than spend tons of times writing pom.xml files.

Regarding alternatives, the only one I know besides homegrown system using Ant is Apache Ivy

Well, for one thing, that survey is hardly accurate considering you saw it on the NetBeans page. If it was conducted by NetBeans (as opposed to a link from NetBeans), then all the more likely that the large numbers of developers not running NetBeans will have missed it. Maven usage is lower compared to Ant, but just how much lower is not really known.

For another, Apache Ant came first. It is still very relevant today because it offers both powerful capabilities and flexibility. Maven encourages a conventional or standardised approach to project structure and build. Most existing projects do not conform to Maven''s convention and hence, many projects are simply not bothered to spend the effort to migrate their already well-crafted Ant build system into another, especially if Maven does not offer anything that their Ant build can already do.

With a Maven based project structure, you can easily enforce SoC (Separation of Concerns) . If you do it wrong and get circular dependencies, maven won''t build.

Maven, used with Releases, Separation of Concerns and Dependency Management is a discipline.

If you want to "hack" your way around it, you could. But then again, I would suggest using Maven as a discipline. You can drive a team with a discipline. Your life becomes several folds harder if you adopt multiple disciplines (say you build one project in Maven and one in Gradle).

Moving to new disciplines involves a company wide appreciation of the reasons for it to exist. Unless you''re a small team, stick with a discipline that has been time tested. Maven has been.

As for Netbeans developers, don''t do it because others do it. It''s like believing in God because others do.

If everybody is on board, try Gradle.