java - tipos - que es un eclipse solar

¿Por qué necesitamos a Maven o Ant, si ya tenemos Eclipse? (5)

Porque su colega podría preferir NetBeans o IDEA
Debido a que la configuración puede variar de una instalación de eclipse a otra
Porque es posible que desee obtener sus dependencias de forma automática
Porque desea automatizar la compilación completa: compilar, jar, aplicar el análisis de código estático, ejecutar las pruebas unitarias, generar la documentación, copiar en algún directorio, ajustar algunas propiedades dependiendo del entorno, etc.
Porque una vez que está automatizado, puede usar un sistema de integración continua que crea la aplicación en cada cambio o cada hora para asegurarse de que todo sigue desarrollándose y las pruebas aún pasan ...
Porque Maven usa la convención sobre la configuración.
Debido a que su IDE puede no ser compatible con la generación / transformación de código de fantasía que necesita.
Porque un script de compilación documenta el proceso de compilación.

Eclipse es un entorno de desarrollo. Pero no es una herramienta de construcción.

Yo personalmente odio a Maven, pero a YMMV. Hay muchas alternativas: gradle, buildr, etc.

Creo que esta pregunta es una extensión de Compare to the IDE for Java, ¿todavía necesitamos Ant?

Hay respuestas para la pregunta anterior, pero deseo conocer un ejemplo concreto del uso de Maven o Ant por encima de Eclipse.

Cuando desarrollo en Eclipse, Eclipse hace todo por mí y solo necesito hacer clic en el botón Ejecutar. Y también, Eclipse puede permitirle exportar su código a un archivo ejecutable o incluso .exe para Windows.

Entonces realmente no sé por qué necesito a Maven o Ant.

Y también si lo necesito, ¿ cuál debería elegir, Maven o Ant?

Hay muchas ventajas en usar Ant o Maven.

Maven es más o menos un concepto de actualización de Ant. En lugar de darle una respuesta de viñeta, he decidido tomar otro enfoque para responder esta pregunta. Te haré una simple pregunta. Supongo que serías un desarrollador; o tiene algún tipo de fondo de programación OO.

Entonces, si su gerente le pidiera que copiara doscientos directorios, pero ignore jar, war and ear archivos jar, war and ear dentro de esos directorios y una vez copiados. A continuación, implementa esos doscientos directorios en otro destino pero implementa solo archivos .class ; copia el resto de los archivos en otro destino, etc.

Para que hagas esto en java; será mucha lógica, mucho código y no sería extensible o adaptable al cambio. Entonces, en mente, Ant o Maven lograrán y prepararán todo esto sobre la marcha con menos sobrecarga para que la use su aplicación. El tamaño del código en ant o Maven será 1/4 comparación con Java.

Haga clic en los enlaces para obtener más beneficios técnicos:

Maven

Ant No pude encontrar una respuesta auténtica con beneficios, pero estoy seguro de que esto te convencería;)

Maven generalmente se usa para construir plugins o jar para una aplicación en particular.

Supongamos que ha desarrollado una aplicación, pero no desea agregar manualmente las jarras necesarias para esa aplicación. En esta situación, Maven o Ant es muy útil. Una vez que haya escrito el código que acaba de ejecutar Ejecutar como -> Maven Build (haga clic en Maven Build), generará todos los plugins o jars requeridos e incluirá en la biblioteca de la aplicación build-path. Puede surgir una duda acerca de cómo la aplicación obtendrá esos archivos jar. Para cada aplicación hay un archivo xml llamado POM.xml donde se guarda la referencia de todos los archivos para su descarga.

Maven me parece un caso de algo escrito por un grupo de críos de script c-shell que creen que autoconf es la automatización de código de vanguardia y no entienden que el código de objeto requiere un entorno de objetos para estar en cualquier forma eficiente para el desarrollo o la implementación. Ant fue lo suficientemente 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, en vivo 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 creación de instancias, etc. Dado que el entorno debe estar completamente activo, no debería necesitar una herramienta de compilación en absoluto. En términos de 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 no 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 punto, tengo un entorno de despliegue 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 Spring VM en una VM Java 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 fusionar su código anterior con las nuevas librerías, fusionar el código usando las nuevas librerías a la versión anterior o conservar ambas versiones. La sugerencia alienta al desarrollador a realizar las ligeras modificaciones que a veces son necesarias para evitar tener veinte versiones de cada biblioteca, mientras que las herramientas como Maven ocultan el hecho de que tiene veinte versiones y da 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 se otorgan 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 exagerados editores de texto, no entornos de objetos, pero si desea utilizar sus herramientas para algo que no cubre los miles de complementos de Eclipse, ambos pueden importar y mantener proyectos de Eclipse, su compilación será extraordinariamente lenta en comparación con los desarrolladores. usando Eclipse, pero, de todos modos, serían tan lentos si fueran proyectos puros de Netbeans o Idea.

No es una razón seria para usar Maven.

La facilidad de exportar / importar ajustes en Eclipse (algo que cada equipo debe hacer en cualquier IDE en cualquier caso) hace que los diferentes ajustes no sean más que pereza por parte del equipo de desarrollo (o un argumento religioso sobre espacios vs pestañas, jajaja) .

Nuevamente, no es una razón seria para usar Maven.

¿Entorno de equipo? Muéstrame un equipo que no use un repositorio como GIT o SVN. ¿Por qué tenemos que duplicar tanto la funcionalidad como el dolor de mantenimiento al configurar repositorios Nexus también?

Esa es realmente una buena razón para NO usar Maven.

Ejecutando una compilación de servidor? La gran idea, ahora, ¿no debería ser iniciada por un código que en realidad está registrado en el repositorio de origen en lugar de una compilación aleatoria que resulta ser enviado a Nexus? Esto trae un punto en contra de Git, particularmente Git con Maven. Como en Git no trabajo en una sucursal, realizo pruebas localmente y luego me comprometo (en parte porque mi prueba local no prueba que la construcción del servidor funcione debido a las diferencias en la configuración de Maven en Jenkins y Eclipse) tengo que comprometer mis cambios a una rama diferente para ver que la creación del servidor Maven falla, y luego realizar un cambio adicional para solucionar el problema, lo que da como resultado un historial de fuente ilegible en el repositorio. El código registrado debe al menos construir y pasar las pruebas unitarias, que si Git y Maven estuvieran fuera de la imagen deberían estar garantizados.

Exportar una construcción sin cabeza desde Eclipse es trivial si realmente lo observas, todo lo que necesitas es hormiga o Gradle, la construcción del desarrollador ya mantenida por Eclipse, y algunos tarros de Eclipse (Eclipse exportará todos los archivos necesarios para una construcción sin cabeza a una directorio o archivo zip, o ftp ellos al servidor de compilación). Las herramientas de compilación de servidores como Hudson / Jenkins pueden extraer código actualizado de la mayoría de los repositorios de origen y llamar a cualquier script de compilación, no hay dependencia en Maven. Con Maven obligas a los desarrolladores a utilizar una herramienta no adecuada para nadie más que ingenieros de construcción (las magnitudes más largas que lleva construir, incluso usando M2E, son suficientes para ese caso), o vives con la posibilidad de que el servidor cree no funciona del mismo modo que la compilación de la estación de trabajo, lo que sigue siendo cierto si se soluciona todo el problema de integrar los dos usando la plétora de complementos M2E. De cualquier forma, obtendrá una compilación de estación de trabajo más lenta y más frágil en aras de una compilación de servidores igualmente lenta y más frágil. En todos los proyectos basados en Maven en los que he trabajado, he visto errores transitorios de Hudson / Jenkins que no aparecen en Eclipse a menos que tenga absolutamente todos los plugins M2E instalados y configurados correctamente, y la mayoría de los desarrolladores nunca lo hacen.

Parece ser otra gran razón para evitar a Maven.

Eso no cubre algunos de los problemas más fundamentales con Maven, como espacios de nombres que rompen espacios de nombres Java y espacios de nombres XML, su unidad de compilación (POM) no tiene relación con nada en el entorno de despliegue real (piénselo, cuando se separa a través de POMs ¿qué está logrando realmente en el producto final? 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 se ejecutan como una sola pieza monolítica de código); 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 afecten y se vean afectados por la configuración de Maven con muy poco sentido obvio; los problemas causados por tratar de ejecutar pruebas unitarias sin un entorno completo para que se ejecute el código; la miríada de versiones no solo de dependencias sino de plugins específicos de Maven (en realidad, he visto el infierno de JAR en la propia construcción de Maven , donde múltiples plugins de Maven usaban dependencias conflictivas, uno de los problemas que se suponía que Maven debía resolver) .

Sí, puedes construir código objeto con Maven. También puede escribir código de objeto puro en C o incluso ensamblador, pero no sé por qué lo desea.

La mejor razón para evitar Maven es la enorme cantidad de trabajo necesario para desmantelar un conjunto de proyectos cuando te cansas de todos los problemas mencionados anteriormente (y muchos otros no mencionados).

La mentalidad, heredada del desarrollo C, de que el ciclo de desarrollo consiste en escribir código, compilar, ensamblar, construir, implementar, probar, volver a hacer, está irremediablemente desactualizado en un entorno de objetos. En algún momento debemos decirle a todas las personas con esta mentalidad que deben volver a aprender a desarrollar, punto. Si lo hace, eliminaría cualquier necesidad de Maven, Git y una serie de otras herramientas que no hacen más que perder el tiempo.

El desarrollo de objetos se debe hacer en un entorno de objetos en vivo, donde un cambio de código se prueba ya que se guarda ya que el objeto modificado está activo. La implementación debe consistir en eliminar artefactos solo de desarrollo de ese entorno, creando un tiempo de ejecución que tenga todo lo utilizado por la aplicación en ejecución en desarrollo y prueba.

Actualmente estoy lidiando con un problema causado por la creación de ensamblajes de implementación para una aplicación OSGi utilizando el complemento maven-assembly. La aplicación funciona perfectamente en el entorno Eclipse, que implementa 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-maven, a pesar de tener un muy buen ingeniero de configuración / construcción cuyo único trabajo es lograr ese proceso. Si nos deshicimos de Maven (muy difícil ahora debido a la cantidad de código, pero es posible) y usamos el plugin BNDTOOLS Eclipse, simplemente podríamos exportar la compilación Eclipse como Ant o Gradle sin cabeza (nota, los desarrolladores OSGi que escriben BND y Los BNDTOOLS no son compatibles con Maven, y por una buena razón, el plugin de Maven está escrito por los desarrolladores de Felix que usan Netbeans y Maven, y no tienen otro entorno en vivo más que al final del ciclo de implementación), donde ambas herramientas configuran el mismo entorno como Eclipse, sin los objetos de la GUI que solo están destinados a desarrolladores de todos modos. El resultado sería una configuración y construcción idénticas para la implementación. Esto ahorraría fácilmente de 2 a 3 horas por día por cada desarrollador que esté gastando en versiones lentas de Maven o M2E, y liberará al ingeniero de configuración / creación para que haga 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. Pretender que está codificando en un terminal VT100 de 1979 en lugar de una máquina moderna no lo convierte en un desarrollador "real", simplemente demuestra que sus métodos tienen 35 años de retraso.

De los desarrolladores en el equipo, ninguno de los otros entiende adecuadamente un entorno de objetos en vivo como Eclipse lo suficiente como para hacer que funcione como un entorno en vivo con M2E y OSGi, y son los principales desarrolladores, simplemente no han estado expuestos a él debido a a la prevalencia de herramientas obsoletas de desarrollo de línea de comando. Solo se dieron cuenta de que era posible hacerlo cuando estábamos programando un par para resolver el problema de configuración y yo estaba compartiendo mi pantalla, haciendo que uno de los miembros del equipo exclamara " así es como se escribe el código tan malditamente rápido", cuando vio mi el cambio de código se prueba instantáneamente en el contenedor OSGi de fondo. Puedo usar un shell bash cuando tengo que hacerlo, como cuando estoy buscando registros en un servidor remoto, de hecho lo hago con bastante eficiencia precisamente para poder salir de ese entorno lo más rápido posible y volver al 21 siglo.

Maven y Ant se utilizan para crear scripts de forma que puedan ejecutarse en trabajos por lotes, como con Jenkins o en la línea de comandos.

De hecho, Eclipse utiliza Ant de forma exhaustiva para crear complementos.

Si aprendieras uno de los dos, aprende Maven, es el que casi todo el mundo usa en estos días (reemplazando a Ant).