Maven me da la impresión de ser un caso de algo escrito por un grupo de niños con scripts de c-shell que ya pasaron su fecha de caducidad y piensan que autoconf es una automatización de código de vanguardia y no entienden que el código objeto requiere un entorno de objeto para estar en de cualquier forma eficiente, ya sea para el desarrollo o la implementación. Ant ya era bastante malo, pero Maven combina todas las peores características de Ant e Ivy. No crea un entorno de objetos y no funciona bien con herramientas que sí lo hacen.
Simplemente, un entorno de objetos debe tener todos los objetos de clase, es decir, los objetos que determinan los tipos de objetos disponibles para el sistema, vivos y disponibles en todo momento. Desde allí puedo hacer lo que quiera, crear instancias de múltiples objetos de una clase, configurar varias secuencias y reglas de instanciación, etc. Dado que el entorno debería estar completamente activo, no debería necesitaruna herramienta de construcción en absoluto. En cuanto a la implementación de mi aplicación, no es difícil para el entorno simplemente descartar todos los objetos de clase a los que el código nunca hace referencia en los espacios de nombres que componen mi aplicación. El recolector de basura en la JVM hace casi lo mismo sobre la marcha hoy. En ese momento, tengo un entorno de implementación compuesto por mis objetos y todos los objetos (principalmente objetos de clase) a los que hacen referencia mis objetos, es decir, mi aplicación y todas las dependencias. Así es como funcionan las máquinas virtuales. (que nuestras VM estén tan mal escritas que necesitamos ejecutar una Spring VM en una Java VM en una VM Linux en una VMWare VM en otra VM Linux es otro ejemplo de la idiotez del desarrollo de software). Cuando las dependencias se actualizan, es lo suficientemente simple para que el entorno solicite al desarrollador que fusione su código anterior con las nuevas bibliotecas, fusionar el código usando las nuevas bibliotecas con la versión anterior, o mantener ambas versiones. Preguntar alienta al desarrollador a realizar las ligeras modificaciones que a veces son necesarias para evitar tener veinte versiones de cada biblioteca, mientras que herramientas como Maven ocultan el hecho de que tiene veinte versiones y dan como resultado la gran cantidad de tiempo de ejecución común en las aplicaciones Java.
En el espacio de desarrollo de Java, Eclipse se acerca más a ser un entorno de objetos adecuado, aunque hay muchos complementos que rompen el paradigma de varias maneras. La mayoría de las razones dadas para usar Maven se desmoronan cuando se examinan críticamente.
Netbeans e Idea son editores de texto exagerados, no entornos de objetos, pero si desea usar sus herramientas para algo que no está cubierto por los miles de complementos de Eclipse, ambos pueden importar y mantener proyectos de Eclipse, su compilación será excesivamente lenta en comparación con los desarrolladores usando Eclipse, pero entonces, serían tan lentos si fueran puros proyectos de Netbeans o Idea de todos modos.
No es una razón seria para usar Maven.
La facilidad de exportar / importar configuraciones en Eclipse (algo que todo equipo debería hacer en cualquier IDE en cualquier caso) hace que el problema de las diferentes configuraciones no sea más que pereza por parte del equipo de desarrollo (o una discusión religiosa sobre espacios frente a pestañas, jejeje) .
Nuevamente, no es una razón seria para usar Maven.
Entorno de equipo? Muéstrame un equipo que aún no usa un repositorio como GIT o SVN. ¿Por qué necesitamos duplicar tanto la funcionalidad como el dolor de cabeza de mantenimiento al configurar también repositorios de Nexus?
Esa es en realidad una buena razón para NO usar Maven.
¿Ejecuta una compilación de servidor? Gran idea, ahora, ¿no debería iniciarse con un código que está realmente registrado en el repositorio de origen en lugar de una compilación aleatoria que se envía a Nexus? Esto trae un punto en contra de Git, particularmente Git con Maven. Como en Git no trabajo en una rama, pruebo localmente, luego me comprometo (en parte porque mi prueba local no prueba que la compilación del servidor funcione debido a diferencias en la configuración de Maven en Jenkins y Eclipse) tengo que confirmar mis cambios a una rama diferente para ver que la compilación del servidor Maven falla, luego realice un cambio adicional para solucionar el problema, lo que da como resultado un historial de origen ilegible en el repositorio. El código verificado debería, como mínimo, compilar y aprobar pruebas unitarias, que si Git y Maven estaban fuera de escena deberían estar garantizadas.
Exportar una compilación sin cabeza desde Eclipse es trivial si realmente lo analiza: todo lo que necesita es ant o Gradle, la compilación del desarrollador ya mantenida por Eclipse y algunos frascos de Eclipse (Eclipse exportará todos los archivos necesarios para una compilación sin cabeza a un directorio o archivo zip, o ftp al servidor de compilación). Las herramientas de compilación del servidor como Hudson / Jenkins pueden extraer el código actualizado de la mayoría de los repositorios de origen y llamar a cualquier script de compilación, no hay dependencia de Maven. Con Maven, usted obliga a los desarrolladores a usar una herramienta que no se adapta a nadie más que a los ingenieros de construcción (las magnitudes más largas que lleva construir, incluso usando M2E, es suficiente para que se desarrolle ese caso), o vive con la posibilidad de que el servidor construya no funciona bastante como la acumulación de trabajo, que es aúncierto si pasa por todas las molestias de integrar los dos utilizando la gran cantidad de complementos M2E. De cualquier manera, obtendrá una construcción de estación de trabajo más lenta y frágil en aras de una construcción de servidor igualmente lenta y más frágil. En cada proyecto basado en Maven en el que he trabajado, he visto errores transitorios de Hudson / Jenkins que no aparecen en Eclipse a menos que tenga absolutamente todos los complementos de M2E posibles instalados y configurados correctamente, y la mayoría de los desarrolladores nunca lo hacen.
Parece otra gran razón para evitar a Maven.
Eso no cubre algunos de los problemas más fundamentales con Maven, como que sus espacios de nombres rompen los espacios de nombres Java y los espacios de nombres XML, su unidad de compilación (el POM) no tiene relación con nada en el entorno de implementación real (piénselo, cuando separe a través de POM, ¿qué está logrando realmente con el producto terminado? Nada. Todo lo que logra es una falsa sensación de que ha separado las preocupaciones y la funcionalidad en diferentes unidades de construcción que todos ejecutancomo una pieza de código monolítica); la molestia de mantener manualmente archivos de configuración complejos, que solo empeora si necesita usar OSGi u otro contenedor y tiene que mantener otros archivos de configuración que afectan y se ven afectados por la configuración de Maven con muy poco sentido obvio; los problemas causados por intentar ejecutar pruebas unitarias sin un entorno completo para que se ejecute el código; las versiones miríada no sólo de dependencias, pero de plugins específicos Maven (De hecho, he visto el infierno JAR en la construcción Maven en sí donde varios plugins de Maven estaban usando dependencias contradictorios - uno de los problemas Maven se suponía que debía resolver .
Sí, puede crear código objeto con Maven. Tu puedes escribir código de objeto puro en C o incluso en ensamblador, pero no sé por qué querría hacerlo.
La mejor razón para evitar Maven es la cantidad de trabajo fenomenal que se requiere para desmavenizar un conjunto de proyectos cuando se cansa de todos los problemas mencionados anteriormente (y muchos otros no mencionados).
La mentalidad, heredada del desarrollo en C, de que el ciclo de desarrollo consiste en escribir código, compilar, ensamblar, construir, implementar, probar y repetir, está irremediablemente desactualizada en un entorno de objetos. En algún momento, debemos decirles a todas las personas con esta mentalidad que necesitan volver a aprender cómo desarrollarse, punto. Hacerlo eliminaría cualquier necesidad de Maven, Git y una gran cantidad de otras herramientas que no hacen más que perder el tiempo.
El desarrollo de objetos debe realizarse en un entorno de objetos en vivo, donde se prueba un cambio de código a medida que se guarda, ya que el objeto modificado está en vivo. La implementación debe consistir en eliminar los artefactos de desarrollo de ese entorno, creando un tiempo de ejecución que tenga todo lo que la aplicación en ejecución utiliza en el desarrollo y la prueba.
Actualmente estoy lidiando con un problema causado por la creación de ensamblajes de implementación para una aplicación OSGi usando el complemento maven-assembly. La aplicación funciona perfectamente en el entorno Eclipse, que implementa en caliente todos los cambios de código en un contenedor OSGi en ejecución dentro del entorno. Sin embargo, la configuración no sobrevive intacta a través del proceso de ensamblaje de Maven, a pesar de tener un muy buen ingeniero de configuración / compilación cuyo único trabajo es lograr ese proceso. Si nos deshacemos de Maven (muy difícil ahora debido a la cantidad de código, pero posible) y usamos el complemento BNDTOOLS Eclipse, simplemente podríamos exportar la compilación de Eclipse como una compilación sin cabeza de Ant o Gradle (tenga en cuenta que los desarrolladores de OSGi que escriben BND y BNDTOOLS noadmite Maven, y por una buena razón, el complemento de Maven está escrito por los desarrolladores de Felix que utilizan Netbeans y Maven, y ningún entorno en vivo que no sea al final del ciclo de implementación), donde ambas herramientas configuran el mismo entorno que Eclipse, sin los objetos GUI que solo están destinados a desarrolladores de todos modos. El resultado sería una configuración y compilación idénticas para la implementación. Esto ahorraría fácilmente de 2 a 3 horas por día por desarrollador que actualmente esté viendo compilaciones lentas de Maven o M2E, y liberaría al ingeniero de configuración / compilación para realizar más pruebas de la aplicación en los hosts de implementación.
Superar la mentalidad de escribir / compilar / ensamblar / construir / implementar / probar es el único impedimento importante. Fingir que está codificando en una terminal VT100 de 1979 en lugar de en una máquina moderna no lo convierte en un desarrollador "real", solo demuestra que sus métodos están desactualizados hace 35 años.
De los desarrolladores del equipo, ninguno de los demás comprende adecuadamente un entorno de objetos en vivo como Eclipse lo suficiente como para que funcione como un entorno en vivo con M2E y OSGi, y son los mejores desarrolladores, simplemente no han estado expuestos a él debido a la prevalencia de herramientas de desarrollo de línea de comandos obsoletas. Solo se dieron cuenta de que era posible hacerlo cuando estábamos programando en pares para resolver el problema de configuración y yo estaba compartiendo mi pantalla, lo que provocó que uno de los otros miembros del equipo exclamara " eso es cómo escribes código tan malditamente rápido ", cuando vio que mi código cambiaba instantáneamente, se probaba a sí mismo en el contenedor OSGi de fondo. Puedo usar un shell bash cuando tengo que hacerlo, como cuando estoy viendo registros en un servidor remoto, en De hecho, lo hago de manera bastante eficiente precisamente para poder salir de ese entorno lo más rápido posible y regresar al siglo XXI.