Admito, todos trabajamos en construir edificios en Maven durante largas tardes y noches, y en ese momento realmente quería contarle a un par de creadores afectuosos de esta maravillosa tecnología. ¡A veces los sueños se hacen realidad! Zhenya y yo (
phillennium ) nos
encontramos con casi el principal desarrollador de Maven: Robert Scholte. Y sobre lo que le preguntamos ...
Leer más →
Con el nuevo ciclo de lanzamiento, las versiones de Java salen una tras otra, la undécima ya ha aparecido, mientras que muchas están en la octava. Pronto hará una presentación sobre cómo Maven apoya todo esto, y no desea estropear el informe, pero haga una pregunta en esta dirección. ¿Qué piensa personalmente sobre este nuevo ciclo de lanzamiento que le agrega trabajo? ¿Es este un cambio para bien o para mal?
Si está hablando de un ciclo de lanzamiento de 6 meses, entonces para Maven es un poco rápido. Nuestro equipo es lo suficientemente pequeño, tenemos entre 5 y 10 participantes activos, y todos son voluntarios, ninguna compañía está desarrollando Maven. Por lo tanto, todos deberían trabajar en el proyecto en su tiempo libre. Los cambios en Java crean mucho trabajo. Cada vez que se lanza una nueva versión, necesitamos proporcionar su soporte, lo que significa que no tenemos tiempo para Maven, complementos para él o cualquier otra cosa. Sería mejor para mí si el ciclo durara un año o medio.
¿Otras personas que desarrollan proyectos para el ecosistema de Java tienen una sensación similar, que también necesitan proporcionar soporte para las últimas versiones?
A juzgar por Twitter, sí, la mayoría está de acuerdo en que 6 meses es demasiado rápido.
¿Podrías contar la historia de Maven? Si no recuerdo mal, fue creado hace mucho tiempo para hacer que la Turbina Apache se construyera menos aterradora y dolorosa. Por cierto, usé la turbina Apache. ¿Te acuerdas de esta vez?
La historia de Maven comenzó hace mucho tiempo. Me uní al proyecto hace unos 8 años, es decir, durante la versión 3.0.3 o 3.0.4. Y en este punto, Maven ha existido por bastante tiempo. Que yo sepa, él formó parte del proyecto Turbine. Se hizo una herramienta separada de parte de este proyecto, que se convirtió en Maven. Yo, como probablemente todo, usé Ant entonces. No me gustó que cada vez que comencé a trabajar en un nuevo proyecto, necesitaba copiar todos estos archivos Ant. Sabía que debería haber una solución mejor, comencé a buscarla en Internet y encontré a Maven. Sin embargo, antes de entender la idea principal de Maven, pasó mucho tiempo. Sin embargo, cuando lo entiendes, se vuelve conveniente. Todos los problemas que tuve con Ant desaparecieron. Ant sigue siendo una gran herramienta, pero si está trabajando en un proyecto que combina muchas fuentes, le recomiendo Maven o una herramienta similar.
Maven es solo sobre Java. Intenté usarlo para C ++, pero no fue muy agradable. ¿Hay algún momento en que Java ya no lo sea, y qué haremos entonces?
De los lenguajes populares orientados a objetos existentes, Java parece ser uno de los más antiguos, ya tiene más de 20 años. No miré las últimas estadísticas, pero estoy seguro de que Java todavía está muy extendido. Creo que existirá por bastante tiempo. Al menos eso espero, significa que no me quedaré sin trabajo.
¿Vivirá Maven demasiado tiempo?
Pero esta es una pregunta difícil. Hasta hoy, el 65-80% de los proyectos Java usan Maven. Incluso para un producto que tiene más de 15 años, esto es mucho. Probablemente, mucho más se puede mejorar en Maven. Tenemos ideas para Maven 4 e incluso Maven 5. Pero llevará mucho tiempo implementarlas. Creo que la idea general de Maven no se volverá obsoleta, pero otros sistemas de ensamblaje pueden superarla. Debido a que extraen experiencia tanto de los errores que cometimos en Maven como de las decisiones que tomamos correctamente, y en base a esta experiencia, pueden comenzar desde cero. Una de las ventajas de Maven es la compatibilidad con versiones anteriores. Incluso un proyecto escrito hace 10 o 15 años puede ensamblarse utilizando la última versión de Maven. Pero debido a esto, tenemos mucho código antiguo en Maven Core. Debería reemplazarse, pero esto no es tan fácil.
Por lo que recuerdo, ahora todavía puedes construir moji sin anotaciones.
Si es posible.
Antes de la entrevista, traté de encontrar un tutorial sobre esto, y no encontré nada. Es como si los langoliers nos persiguieran y se estuvieran comiendo todos los documentos viejos en Internet. Pero recuerdo que alguna vez no hubo anotaciones y se usaron convenciones especiales. Bueno, él, pasemos a otra pregunta. ¿Crees que Maven tiene una competencia real? Decir gradle?
Gradle es un competidor muy fuerte, y ha existido durante bastante tiempo. Creo que tener competencia es bueno, porque nos mantiene en forma y nos permite ver algunas soluciones alternativas. Simplemente tienen un enfoque diferente sobre cómo recopilar proyectos, no hay nada de malo en eso. Todos deberían elegir lo que mejor se adapte a su proyecto. Quizás también debería mencionar pro aquí . Esta es una herramienta escrita por Remi Forax del equipo de ASM (analizador de bytecode). Él, como yo, era miembro del grupo de expertos del proyecto Jigsaw. Quería escribir una herramienta de compilación que reflejara mejor las ideas de Java. Al crear profesional, tomó prestados los mejores aspectos de Maven. Ver esto fue interesante. Fue una demostración diseñada para mostrar que puede usar módulos Java 9 y beneficios relacionados en el generador.
Dijiste que participaste en el proyecto Jigsaw, y lo dijiste en tiempo pasado. Él dejó de existir? ¿Todavía tiene la oportunidad de desarrollarse?
Este JSR está cerrado. Es cierto que algunos problemas no resueltos permanecieron, pero ahora son resueltos por el equipo de soporte.
¿Qué causó la mayoría de las dificultades para desarrollar Maven? ¿Cuáles fueron los problemas más serios? No en términos de Java 9, sino en general, basado en toda la experiencia de desarrollo. ¿Puedes elegir, digamos, los dos problemas más importantes?
La pregunta no es fácil, pero probemos. La parte en la que se produce la resolución de dependencia es extremadamente compleja. Todavía estamos tratando de mejorarlo. Es posible que haya notado que no había una versión Maven 3.4, después de la versión 3.3.9 hubo inmediatamente 3.5.0. La razón principal de esto es que ha habido cambios significativos en la resolución de dependencias. Se marcaron como correcciones de errores, pero notamos que un número significativo de proyectos se interrumpieron repentinamente; dependían de estos cambios extraños. Esto fue inaceptable. Por lo tanto, hicimos lo que no habríamos tomado bajo ninguna otra circunstancia: un repositorio git de restablecimiento completo, y en Maven 3.5.0 comenzamos a seleccionar solo mejoras externas. Bueno, y, por supuesto, hicimos la consola multicolor; a todos les gustó.
Ok, ahora es la segunda dificultad!
No fue fácil para nosotros encontrar una conexión con la comunidad Maven y enseñarles cómo usar la herramienta correctamente.
Por lo tanto, todos saben cómo usar Maven: copie algunas huellas XML de los comentarios en Stack Overflow, y funciona. ¿No es así?
Bien bien No Estoy seguro de que la mayoría de las veces se le recomendará que realice una instalación limpia, y esto no es cierto. Entonces, probablemente, debería hacerse en Maven 2. Ahora necesita ejecutar mvn verificar. Porque cuando limpia, todo se elimina, todo el resultado del trabajo. Y si los archivos se copian de usted, estas son operaciones de E / S, son lentas. En general, muchas cosas se harán muchas veces. La mayoría de los complementos saben cuándo necesitan hacer su trabajo. Como regla, no hay necesidad de limpieza. En cuanto a la instalación, este comando solo copia sus archivos JAR en el repositorio local. Esto, nuevamente, es una operación de E / S innecesaria. Además, su repositorio local puede ensuciarse, es decir, puede verse diferente al repositorio local de su colega. A veces esto puede conducir a resultados interesantes. Entonces deberías ejecutar mvn verificar, eso es suficiente.
Por cierto, acabo de abrir maven.apache.org y dice: "Apache Maven es una herramienta de comprensión y gestión de proyectos de software". Pero mucha gente piensa que Maven es solo otra herramienta de construcción. ¿Cuál es la diferencia entre una herramienta de ensamblaje y una herramienta de gestión de proyectos?
Probablemente sea mejor no responder esta pregunta; no fui yo quien lo escribió en el sitio. Creo que el autor quería decir que Maven es mucho más que solo construir un proyecto. También está involucrado en la resolución de dependencias, proporciona un formato de configuración, permite no instalar demasiadas cosas. En general, esta es una gran colección de todo en el mundo.
¿Cuáles son los principios y creencias principales del equipo de Maven? Por ejemplo, ¿piensan que un enfoque declarativo es mejor que un imperativo? Algo como Zen en Python. ¿Tienes un conjunto similar de reglas?
Creo que no En nuestra opinión, la configuración de los complementos debe hacerse lo más simple posible. Si existen valores predeterminados razonables, deben indicarse. Esto facilitará la vida del usuario final. Por primera vez en muchos años, recientemente cambiamos la opción predeterminada para las versiones de origen y destino: antes era 1.5, ahora es 1.6. Queríamos que la opción predeterminada estuviera presente, porque sin ella se usa la versión utilizada en el JDK. En este caso, si uso Java 10, y alguien más usa Java 12, tendremos resultados diferentes. Siempre debe especificar el origen y el destino. Pero si comenzó a usar Java 9, ya no puede crear Hello World con un simple archivo pom y una clase, ya que Java 9 requiere al menos Java 6 para los valores de origen y destino. Por lo tanto, decidimos hacer la versión predeterminada 1.6 y agregamos una advertencia de que si aún no ha especificado una versión, esto debería hacerse; las personas deben saber que necesita establecer las versiones de origen y destino o el valor de lanzamiento si está trabajando con Java 9. O ambos.
¿Qué dificultades ves para Maven en el futuro? Dijiste que intentas no cambiar a Maven con demasiada frecuencia. Y sin embargo, ¿qué nos espera en el futuro?
Uno de los cambios más significativos que queremos hacer se relaciona con el archivo pom. Descubrimos que en algunas secciones, especialmente en la compilación, sería bueno agregar algunos elementos adicionales. Pero por ahora, no podemos hacer esto. Se carga el mismo archivo pom que usa en su sistema. Si le agrega otros elementos, violarán el XSD y otras herramientas no podrán usarlo.
Pero, ¿puedes cambiar el XSD en el encabezado?
Si Pero no creo que todas las herramientas comprueben el XSD. Simplemente piensan que están tratando con la versión 4.0.0. Entonces hacer cambios será muy difícil. Decidimos dividir el archivo pom en varias partes y comenzar con Build POM. Y el que se descargará se llamará Consumer POM. Se generará en función del Build POM y no se requiere ninguna otra acción. Y será totalmente compatible con Maven POM 4.0.0. Al dividir el POM en dos partes, finalmente podemos mejorarlo significativamente y hacer que Maven sea más fácil de usar. Este es un cambio en el núcleo de Maven, y hemos estado trabajando en ello durante más de un año, incluida la implementación en el IDE. Esto no es facil.
Algunos IDE intentan incluir partes de Maven en el IDE por razones de integración, autocompletado, compilación incremental, etc. ¿Cómo hacerlo bien? Por lo que recuerdo, algunas partes de Maven se construyeron en Eclipse hace mucho tiempo.
Creo que tales intentos están justificados: este sistema fue muy conveniente para los usuarios debido a la integración. Esto fue posible gracias a uno de los cambios significativos implementados en Maven 3. En él, la arquitectura se rehizo para proporcionar un mejor soporte en el IDE. Los autores de estos cambios trabajaron estrechamente con Eclipse, y esta solución vino de aquí. Creo que esto es permisible. Sé que NetBeans e InelliJ tienen un enfoque completamente diferente, simplemente llaman a Maven desde la línea de comandos sin ninguna integración.
Otro tema importante es la velocidad de Maven. ¿Podemos de alguna manera aumentarlo? La resolución de dependencia y las operaciones de E / S son muy lentas. Incluso hoy en un SSD.
Sí, se puede hacer algo. Primero debe ver cuántos núcleos hay en su sistema e iniciar Maven con varios subprocesos. Esta es una de las soluciones. Además, eche un vistazo a Takari. Esta es una empresa creada por Jason van Zayl, uno de los fundadores de Maven. Escribió algunas extensiones interesantes y mejoró significativamente el soporte para ensamblajes paralelos, es decir, cuando construyes varios proyectos. Espero que algún día le dé estos desarrollos a Maven, pero por ahora deberías echarle un vistazo a su página.
Dijiste que estabas trabajando en Maven en tu tiempo libre, ¿verdad? ¿El hecho de que seas uno de los creadores de Maven te ayuda en tu trabajo actual? ¿O es solo un pasatiempo?
Trabajo como arquitecto de software en una organización gubernamental en los Países Bajos. Así es como me gano la vida. Por supuesto, saben que yo también trabajo en Maven, por lo que periódicamente me hacen preguntas sobre Maven. Pero en general, solo soy su arquitecto. Y por las tardes, trabajo en Maven, trato de mejorarlo, ayudo a la gente.
¿Trabajas en otros proyectos de código abierto además de Maven?
Participo en otros dos proyectos. Uno se llama MojoHaus, desarrolló una parte significativa de los complementos para Maven. Es cierto, ahora hago poco en este proyecto, pero aún así a veces miro allí y descarto varias cosas pequeñas. Otro proyecto se llama QDox. Analiza el código fuente. También está asociado con Maven, ya que se usa en algunos complementos para ello. Esta experiencia me ayuda, porque, por ejemplo, en el caso del descriptor de módulo, introducido en Java 9, la experiencia me permitió usar un descriptor en complementos para Maven.
Por cierto, ¿cuál es su opinión sobre Java 9, 10, 11? ¿Debo usarlos, o es mejor quedarse con Java 8?
Migrar a versiones más nuevas. Incluso si no está utilizando todas las funciones, debe actualizar a Java 10, o esperar algunas semanas y actualizar a Java 11. Solo use classpath. Java es significativamente más rápido gracias a su modularidad, pero el classpath simplemente funciona. Sé que muchos todavía piensan que necesita agregar un descriptor de módulo o usar un sistema de módulo, pero esto no es necesario. Solo usa classpath.
Por cierto, ¿estás familiarizado con el proyecto GraalVM? ¿Qué tal si lo usas para construir Maven?
La semana pasada visité JavaZone y discutí esto con Chris y Oleg. Creo que necesitaremos pasar un tiempo con esto, ver si es posible mejorar realmente el rendimiento de Maven con GraalVM. Puede ser interesante
Eres el creador de Maven, un proyecto que es muy importante para los desarrolladores de Java. ¿Cuáles son tus sentimientos sobre esto?
No soy el fundador del proyecto, estoy comprometido con su apoyo. Comencé a tratar con él cuando ya había recorrido un largo camino, y parece que lo entiendo aceptable. Hace diez años, no hubiera pensado que terminaría en la cima de la jerarquía, pero sucedió, y es genial. Todos tienen una opinión sobre Maven, y eso me gusta mucho cuando vienes a la conferencia, la gente se acerca y dice que está encantada con Maven. Esto me motiva mucho y me da fuerzas para seguir trabajando en el proyecto cuando regrese a casa.
Muchos desarrolladores odian vehementemente el XML. No soy uno de ellos, pero cuando se trata de construir sistemas, este tema siempre aparece debido a pom.xml en Maven. Por lo tanto, quiero saber: ¿cuál es su opinión sobre XML?
Lo bueno de XML es que todo el mundo lo entiende, es fácil analizarlo y puede proporcionar muy buen soporte en el IDE. Soy bastante normal con XML, y que yo sepa, entre los usuarios de Maven no más del 5% odia XML, ¡pero lo gritan en voz alta! Y simplemente nunca escuchas el 95% restante. Sin embargo, hay una solución para este 5%, aquí nuevamente quiero mencionar a Takari. Hay un proyecto políglota que le permite seleccionar una sintaxis diferente. Entonces, si desea usar Yaml y pom.yml, esto es completamente posible. Solo necesita agregar extensiones al proyecto, y puede cambiar a otro idioma.
Y también sobre el estado de ánimo de los desarrolladores: recuerdo el hilo en la lista de correo de Maven, ¡dónde está el autor de la herramienta SDKMAN! la comunidad respondió a la propuesta de distribuir a través de él el Maven con frases como "todo lo que veo es un proyecto con un nombre estúpido" y "podrías vender mejor tu idea". Entonces surgieron discusiones: algunos sintieron que la comunidad había reaccionado de manera demasiado agresiva, otros que la oración inicial "realizar acciones adicionales en relación con mi herramienta" era infundada. De una forma u otra, muchos no estaban contentos con la situación, y a este respecto la pregunta: ¿cree que específicamente Maven o la comunidad de código abierto en general tienen problemas de comunicación?
La comunicación puede ser muy, muy difícil, eso es seguro. Especialmente cuando sucede solo a través del texto y no ve al interlocutor frente a usted; en esta situación, se hace difícil explicar lo que quiere decir. Creo que cada proyecto de código abierto enfrenta este problema de comunicarse correctamente con las personas. Entiendo completamente por qué los participantes del proyecto a veces se molestan: escuchan las mismas preguntas una y otra vez. Un ejemplo de tal pregunta, que ya mencioné, "¿por qué no puedes usar mvn clean install"? Dejé de explicar esto, porque de lo contrario me habría convertido en una persona grosera, pero no quiero esto. Entonces explico tales cosas de otras maneras. Entonces, por un lado, la comunicación puede ser muy difícil. Por otro lado, aunque Maven es inflexible, es parte de su éxito. Cuando las personas presentan ofertas que son incompatibles con nuestro concepto Maven, simplemente decimos: lo siento, pero esto no nos conviene por alguna razón. Entiendo completamente que esto puede ser frustrante. Pero en general, este enfoque es solo para el mejor.
¿Podría, al final, decir algunas palabras a nuestros lectores, sugerir cómo pueden llegar a un futuro brillante?
Como dije, un pequeño equipo está trabajando en Maven, es un proyecto de código abierto en el que todos pueden participar. No es tan dificil. Creamos una nueva etiqueta llamada en juego. Estos son problemas que no deberían ser demasiado difíciles de solucionar. De esta manera, puedes conocer cómo funciona Maven. Si desea unirse a nuestro equipo, entonces, con el ejemplo de sus soluciones, veremos la calidad de su código; si desea que nos noten, le recomiendo que lo pruebe. Realmente me gustaría que nuestro equipo crezca en el futuro.
Gracias por las respuestas ¡Nos vemos en Joker 2018!
Minuto de publicidad. La conferencia Joker 2018 se llevará a cabo del 19 al 20 de octubre, en la que Robert hará una presentación sobre "Apache Maven es compatible con TODO Java" . En general, habrá muchos más informes interesantes y notables en Joker. Las entradas se pueden comprar en el sitio web oficial de la conferencia.