//RANT ON
Debo confesar que mi primera idea para el titulo, llevado por la frustración, era "Mierda de Maven", y eso era lo más fino que se me ocurría, pero teniendo en cuenta que por mi parte odio los titulares amarillistas en los posts de los blogs, he decidido ser coherente y poner algo más neutro, o casi :).
La cuestión es que llevo unos días intentando transformar un proyecto de infraestructura desde Ant a Maven. Lo reconozco, nunca he sido fan de Maven pero resulta que quiero poder distribuir este proyecto en repositorios Maven y los buenos chicos de SonaType ofrecen hospedaje gratutito de repositorio a los proyectos open source. Eso sí, usando Maven para crear y subir las "releases" etc.
Así que después de mucho resistirme, me dije "¡amos a probar, hombre!" y como dicen los anglos decidí "morder la bala" (bite the bullet) o agarrarme los machos, como más os guste. Por el camino tuve que abandonar algunas cosas, como los productos del proyecto que no son .jar (tengo/tenía un .zip y un .xpi), y plegarme a las convenciones que los creadores de Maven consideran que son las buenas. Todo sea por la causa.
Pero bueno, después de unas cuantas peleas, unos cuantos insultos al aire y mucho Google + prueba y error, consigo tener el proyecto montado más o menos como quiero. Los otros artefactos los hago con Ant y al final dejo un proyecto padre y un subproyecto. Sigo las instrucciones para desplegar los artefactos en el repositorio de Sonatype (ver Sonatype OSS Maven Repository Usage Guide) y después de unas cuantas maldiciones más consigo desplegar unos SNAPSHOT e incluso una release. Y aquí llega el detalle: Como repositorio de versiones uso Mercurial, para poder tener siempre el histórico conmigo, cosa muy útil hoy en día donde los repositoros públicos te pueden hacer alguna jugada, y para colmo de males desarrollo en Windows (ya, ya, nadie es perfecto) así que cuanto intento perfeccionar mi pom.xml para que no tenga ningún path absoluto, me encuentro con que la propiedad ${basedir}devuelve siempre el path en Windows con barras invertidas (backslahes) y que el modulo SCM no entiende la URL tal como se la pasa esa propiedad. Bueno,un detallito, nada que Google no pueda arreglar, ¿verdad? Pues no, Google nos responde que ese problema es muy, pero que muy, común y que realmente "no hay solución" que no sea dar trescientas vueltas al mundo, constuir un plugin hacer unas cosas extrañísimas. Madre mía.
Entonces decido que si no lo puedo sacar automáticamente, quizá si se lo paso en un fichero de propiedades y que cada usuario se apañe configurando.... ¡MEEEC! ¡Error! ¿A quien se le ocurriría poder leer algo que no esté en el pom.xml? Debe ser únicamente a los extraterrestres por que Maven lo vuelve a poner complicadísimo simplemente para leer un p|@#@# fichero de propiedades y usarlas en el pom.xml. Lo más aproximado a lo que quiero requiere un plugin que he encontrado, el cual está en estado alpha y ni siquiera en los repositorios oficiales...
Así que sí, Maven permite hacer cosas "complicadísimas" de forma fácil por que te vienen hechas, pero algo tan "simple" como producir un artefacto que no sea .jar/.rar/.war/.ear, obtener un path normalizado o leer un fichero de propiedades es como para sacarse un master.
¿Por qué es el mundo tan cruel?... ¿por qué?... ¿por qué? :(
//RANT OFF
Happy coding! EJ
Maven-assemblye es un plugin que te permite crear artefactos que no son los basicos, por ejemplo yo empaqueto una aplicacion en un .zip y todo me lo hace bien.
ResponderEliminarMaven es una gran herramienta, aunque como toda gran herramienta hay que saber usarla para sacarle el mayor provecho sin tanta maldicion jejeje. Bueno suerte para la proxima.
Maven es el típico ejemlo de los problemas que crea la "programación declarativa", la programación declarativa está muy bien pero sólo resuelve los problemas más convencionales, más obvios, en mi opinión el título debería ser "Maven: como hacer MAS fácil lo fácil y CASI IMPOSIBLE lo difícil"
ResponderEliminarLa clave del éxito de Ant es esa mezcla de programación declarativa y programación imperativa lo cual no encuentras en Maven cuyas deficiencias se resuelven a base de plugins que introducen más programación declarativa. No es serio que haya buscar un plugin para hacer una acción concreta, una buena plataforma debe proporcionar una base programática para que más o menos esfuerzo puedas hacer cualquier cosa, esto es posible a base de plugins hechos en Java con una arquitectura pensada para extender Maven no para solucionar problemas de proyectos concretos aunque esto último es posible pero me parece poco serio tener que extender una herramienta para un proyecto concreto.
Afortunadamente existe un plugin para usar Ant
dentro de Maven.
@hkadejo: Vi el plugin assembly, pero a no ser que yo lo haya entendido mal, sirve para hacer unos cuantos artefactos más (comprimir todo el proyecto en un .zip o .tar.gz, o el target...) pero no para coger un directorio del proyecto dado y simplemente comprimir eso, y no digamos si encima quieres que aunque sea un zip su sufijo sea... .xpi? Cuando lo vi pensé que había encontrado la solución, pero no :(.
ResponderEliminar@jmarranz: No, si no tienes que convencerme de que la cosa no es seria, pero al final he caído por la cuestión de poder publicar los "artifacts" a través de SonaType. Pero de momento no pienso usarlo para nada más, así que prefiero no entrar en mezclarlo con Ant. A veces es más engorroso y menos estandar, pero para mí: Ant + Ivy FTW!
PD: Al final lo que he hecho ha sido pasar el path con las barras correctas como parámetro desde la linea de comandos. En fin, como solo lo necesito para cuando hago una release...
Me olvidaba, más que el problema de la programación declarativa, yo creo que el problema de Maven es que la base que te da es mínima mínima y los "por defecto" están hechos con anteojeras como los caballos en ciudad.
ResponderEliminarSi coincide por donde quieres ir tú, "estupendo", si no, prepárate para el infierno.
Mejor no sigo que me caliento :)
A lo mejor lo que voy a decir es una tontería, pero a la hora de indicarle al SCM el path, ¿le antepones file://?
ResponderEliminarjmarranz: "...La clave del éxito de Ant es esa mezcla de programación declarativa y programación imperativa..."
ResponderEliminarTe recuerdo que todo lo que se hace en ANT se puede hacer en Maven dado que en Maven se pueden ejecutar tareas ANT, con lo cual podrías tranquilamente tener tu pom.xml y que ese pom ejecute en la fase que mejor te convenga las tareas del build.xml que mantienes en ANT.
Saludos, Diego
@Ramón: No, no es exactamente una tontería pero sí, sí lo había probado :).
ResponderEliminar@Diego: Si, se puede tener ambas cosas a la vez, pero así acabas, IMHO, con lo peor de ambos mundos y en mi pueblo dicen que "para ese viaje no hacen falta alforjas". ;)