viernes
jun292012
Sistemas de build en Java: Maven a la cabeza seguido de lejos de Ant
AbrahamYa tenemos los resultados de la encuesta sobre sistemas de build en Java: el 60% de los encuestados emplea principalmente Maven, mientras que sólo el 31% emplea principalmente Ant. Gradle (que recientemente ha llegado a su versión 1.0, lo que fue el desencadenante de esta encuesta) es usado por el 4%. Podría parecer una cifra baja, pero no está mal para acabar de anunciar su primera versión estable.
Cuando preguntamos por qué sistemas de build empleaban, independientemente de si era el que se usaba principalmente o no, Ant es usado en un 62% de los casos, aunque Maven sigue por delante (78%) y Gradle en un 9%. Aquí tenéis una gráfica resumiendo los resultados:
|
¿Qué sistema de build empleas principalmente?
|
|||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||
|
¿Qué sistemas de build empleas?
|
|||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||
Reader Comments (17)
Yo creo que sale mucho porcentaje en el maven porque los que no usan maven usan "la compilación que viene con el IDE".
imagino que los valores que están a la derecha de cada gráfico es absoluto y no en porcentaje....
saludos
lo quiero por que me ahorra tiempo creando mis proyectos lo odio por que igual nunca ponen en la documentacion cual o cuales(en el peor de los casos) son los comandos para construir
Lo que me sorprende es el bajo uso de Ivy,
¿como hacen la gestión de dependencias los que usan Ant en vez de Maven?
@logongas
Basta con usar un buen IDE.
logongas, lo que pasa es que Ivy no debería estar ahí por que Ivy no es un sistema de "build", es sólo la parte de gestión de dependencias y por tanto, si usas Ivy estás usando, normalmente, Ant.
Y usar un buen IDE no tiene que ver con usar Ivy o no, choces, los IDE no hacen gestión de dependencias, como no sea a través de plugins de Maven/Ivy. Son complementarios.
@junio
Uso netbeans, pero no me parece que me ayude mucho.
Desde NetBeans simplemente le digo la carpeta donde tengo mis librerías, pero éstas no se actualizan si cambia la versión (lo cual en mis proyectos es lo que me interesa).
¿Conoces este procedimiento?
http://wiki.netbeans.org/MigrateClassLibraries
@Komorr
Me estoy preguntando cómo he conseguido, a lo largo de varios años, realizar los builds de múltiples proyectos interdependientes entre sí, junto con las dependencias de librerías externas.
Desde hace un par de años, sigo preguntándome cómo consigo hacer los builds de proyectos de NetBeans Platform, que dependen de diversas suites, junto con dependencias externas igualmente.
Todo ello sin añadir al IDE absolutamente ningún plugin al respecto.
Perdonadme un poco de mala leche ¿es TAN IMPORTANTE que en CADA EJECUCIÓN se evalúen las dependencias?
Pongo un ejemplo buscando el absurdo: considerad que ejecutáis un programa ¿consideráis de sentido común que el sistema operativo antes de ejecutar un programa se conectara al servidor de actualizaciones y si encontrara actualizaciones se las bajara y las instalara y luego ejecutara tu programa que con gran probabilidad no necesita dichas actualizaciones?
Quiero decir que me parece muy bien lo de la gestión automática de dependencias pero la instalación/configuración de las dependencias en un proyecto es algo que implica el 0.001% de la duración de un proyecto por lo que entre la gestión manual y automática la diferencia es prácticamente nula, por no hablar de la resolución de conflictos y si una herramienta me hace comulgar con ruedas de molino como es el caso de Maven por una mejora en comodidad del 0.001% del trabajo de un proyecto...
Que sí, que Maven se ocupa además de todas las fases del build de un proyecto... pero de la forma más brutalmente rígida e intrusiva (hasta te fuerza el layout del proyecto) que he conocido.
Debe de ser una "rara casualidad" que solamente un 10% de los usuarios de NetBeans usen Maven ;)
http://statistics.netbeans.org/analytics/graph/projecttypes.jsp
@choces
Eso es útil si cambias la versión de NetBeans, yo me refería a la versión de la librería.
@jmarranz
En mi caso si. El proyecto se divide en dos partes, una serie de librerías y la propia aplicación web y son desarrolladores distintos y se están desarrollando el paralelo. Desde la aplicación Web necesitamos ver cuanto antes los cambios que se producen en las librerías. Así que en cada ejecución si obtengo la nueva versión de todas las librerías en una ventaja.
@logongas
Puesto que en NetBeans se puede declarar cualquier proyecto como dependiente de otro, al igual que se hace con las librerías externas, sigo sin ver dónde está el problema.
A menos que se quieran usar versiones diferentes de la misma librería simultáneamente, lo que implica un tipo de problemas que intenta resolver el diseño modular (hasta cierto punto).
Por supuesto, si se usan diferentes IDE para desarrollar el mismo proyecto, es necesario recurrir a Maven, u otro sistema similar de build.
@choces
Inicialmente era el planteamiento que usaba:Tener dependencias entre proyectos en Netbeans pero:
Me obliga a bajarme un código fuente que no necesito ya que solo quiero los binarios.
Los otros proyectos siempre deben estar en las mismas carpetas (aunque sea de forma relativa) unos respecto a otros para que puedan verse al bajarlos desde cualquier ordenador.
Al montarlo todo en un entorno de integración continua también debes incluir los otros proyectos al compilar el que yo uso.
Y como tu ya has dicho obliga a que todos programen en NetBeans.
Así que me monté un Artifactory donde se publican los binarios y con Ivy me puedo bajar la última versión cuando quiera.
@choces Si dejaras la ironía y la soberbia y leyeras lo que he puesto, quizá entenderías lo que quiero decir. Si lo que hace los IDEs lo quieres entender por "gestión de dependencias" como lo que hace Ivy/Maven, pues perfecto.
Discutir a ese nivel se lo dejo a los de tele5
@jmarranz En mi caso (Ant/Ivy), lo que hago es simplemente comprobar si el fichero que declara las dependencias ha cambiado, y en ese caso no re-compruebo las dependencias. Con un target para re-comprobar a voluntad, en caso de dependencias "dinámicas" donde te bajas el último snapshot, ya tienes cubierto lo necesario y sólo descargas lo que hace falta.
@jmarranz: Pues claro que es importante, no estás ejecutando un bloc de notas, estás ejecutando la fase de construcción de una aplicación que depende de multitud de librerias de terceros con sus propias dependencias transitivas, algunas pueden ser incluso versiones vivas de librerias o componentes propios.
Y además no veo el inconveniente. La primera vez tardará un rato (sobre todo si no tienes un repositorio a nivel de tu organización) pero las siguientes veces si no hay cambios el retardo es mínimo.
Por otro lado, el "layout" tb es configurable. Aunque a mi me parece genial que poco a poco se imponga un estándar, aunque sea defacto, y que viene de la mano de gente que se ha enfrentado a muchos más proyectos que yo.