Que trae de nuevo Eclipse Luna

Como todos los años, viene mi review de que puede parecer interesante en la nueva versión de Eclipse. Este año eligieron una palabra bien "castellana", le tocaba a la letra "L" (el nombre anterior había sido Kepler y el anterior Juno): Luna.
Lo más llamativo de esta versión es el soporte para java 8, pero ya veremos eso con más detalle. Inicialmente podemos apreciar un nuevo logo mucho más flat, acorde a estos tiempos. El splash-screen es mucho más chico y sobrio que antes, me parece acertado el cambio, lo hace más serio y más maduro. A simple vista parece mucho más rápido que las versiones anteriores, seguramente asociado a las mejoras que continuamente se implementan relacionadas a la performance.
Para repasar, comenzaremos con las mejoras en la plataforma, lo primero que llama la atención, es tener por fin el soporte para split editors, algo que es muy interesante y se puede acceder con un par de atajos de teclado.
Otra cosa interesante es el agregado de un nuevo tema dark, a simple vista me parece muy bueno, pero no me gusta como quedan algunos iconos, ya que se ve que quedan pixeles blancos en el borde (algunos fueron rearmados con formato png, pero quedan varios con problemas de transparencia todavía), es algo que deberían mejorar. Lo bueno, sin embargo, es que al fin lograron implementar de que no sea necesario reiniciar la IDE para que tome los cambios del nuevo tema seleccionado.
Nuevo theme
Otra de las cosas nuevas es que ahora hay dos modalidades para las vistas minimizadas, una que es la original, en la cual se muestran "flotando" sobre las demás vistas, cuando uno hace click en el ícono correspondiente; y una nueva en la cual en vez de mostrar la vista superpuesta, se muestra en su ubicación original. Personalmente creo que me sigo quedando con la versión original ya que prefiero que no afecte el layout de las demás vistas.
Otro de los pequeños detalles que si hacen la vida del programador un poco más fácil, es la opción de abrir un explorador de windows en la ubicación en la que se encuentra un archivo. Para acceder a esa opción, click derecho sobre el archivo, "Show in" y luego "System Explorer".
Bueno, luego moviéndonos a las mejoras para los desarrolladores java, la estrella es el manejo de la sintaxis nueva que trae java 8. Lo mejor es la conversión automática de código que puede representarse de mejor manera usando expresiones Lambda. Se puede hacer en un método específico o a nivel global.
Soporte para expresiones lambda
También se puede convertir de expresiones block a expresiones body de un solo paso y ver el método implementado por la instancia de la interfaz utilizada, simplemente pasando el mouse por encima del símbolo "->" o el "::".
Con la venida de las anotaciones de tipo (JSR 308), el compilador de eclipse lleva el análisis de posibles NullPointerExceptions al siguiente nivel, ya que prácticamente puede detectar todos los errores de este tipo en tiempo de ejecución. Solo es necesario utilizar las anotaciones @Nullable y @NonNull de forma correcta en la definición de los parámetros de los métodos.
El depurador también ganó nuevas características relacionadas a lo nuevo que trae java 8, como por ejemplo poner breakpoints adentro de las expresiones lambda.
Eso en lo que respecta a una pasada muy por arriba de las cosas nuevas en la versión base. También como es de costumbre, hay numerosos cambios en todo el ecosistema de plugins de este megaproyecto.
En fin, me parece que este año se notan un poco más las mejoras que en lo que fue kepler, más que nada por lo que es java 8. Igualmente se nota que el esfuerzo se imprime sobre los plugins y no sobre la IDE que sigue bastante parecida a la primer versión.
Alguna otra funcionalidad que valga la pena mencionar?
Saludos!

Notificaciones automáticas de cambios incluidos en un release usando Maven

Hola todos!
Hace tiempo que no escribía, así que acá va una nueva entrada. Antes que nada, los que habrán leído alguna nota el año pasado o antes, habrán notado que la dirección del sitio cambió, la idea es apuntar un poco más a novedades y noticias en el mundo de los frameworks de las plataformas que manejo, con algún comentario de las cosas que me parecen interesantes, veremos si puedo llevarlo adelante.
Hoy quiero contarles acerca la experiencia que tuve, al querer implementar algo que, a priori, hubiera parecido bastante simple de hacer en el mundo de Maven, pero que, sorpresivamente no lo fue. De hecho fue la primera vez desde que utilizo esta herramienta, que tuve que tocar algo de código de un plugin desarrollado, ya que ninguna de las opciones que encontré pudo funcionar.
Lo que necesitaba (o mejor dicho, quería implementar) era poder enviar notificaciones automáticas vía correo electrónico, a los desarrolladores, cuando alguien hacía un release de uno de los componentes que utilizamos internamente en el lugar en donde trabajo.
Lo primero que hice, fue investigar dos plugins que realizaban parte de la tarea:
  • Maven Changes Plugin: Este plugin construye una página o notificación, enumerando los "cambios" que tuvo un artefacto dado. Además ofrece la posibilidad de enviar el anuncio vía correo electrónico. Ya se lo que pensarán, este es el indicado, pero no. El problema es que elabora todo en base a dos orígenes: un archivo .xml que lista los cambios (changes.xml), o sino utiliza un repositorio de issues como Jira o Trac. Justamente en mi trabajo no usamos ninguno de esos repositorios de issues por lo que ninguno de los orígenes de "cambios" me servía. Yo necesitaba que tome los mismos del SVN (repositorio de código).
  • Maven Changelog Plugin: Este otro tenía justamente lo que el anterior no tenía, es decir, lo que hace es elaborar un reporte que lista los cambios que existen en el repositorio de código. El problema es que es lo único que hace (o sea, no arma anuncios ni envía correos). Además el reporte es bastante pobre, ya que no "decora" de ninguna manera los commits, no enlaza los issues a nuestra herramienta de gestión de issues, ni nada por el estilo.
Bastante decepcionado seguí buscando a ver si encontraba algo que podría servirme sin éxito. Hasta que ingresé al repositorio de plugins de Codehaus. Buscando en este lugar, encontré un plugin bastante interesante, el SCM Changelog Maven plugin. Inicialmente parecía ser la solución, ya que creaba un reporte bastante parecido al que genera el Maven Changes Plugin, pero lamentablemente no enviaba anuncios. Igualmente lo investigué para por lo menos poder crear el reporte, pero me encontré con otros problemas:
  • Cuando quise ejecutarlo, me encontré con que arrojaba una excepción, buscando en la lista de issues abiertos, lamentablemente encontré que el problema no estaba solucionado aún.
  • No encontré ninguna configuración que permita filtrar los textos de los commits, esto era importante debido a que como utilizamos releases automáticos vía maven, muchos textos sería interesante que no aparezcan, ya que se trata de commits automáticos.
  • Si bien soporta el concepto de Grammars, para identificar los issues que uno menciona en los textos de los commits, necesitaba la posibilidad de definir una grammar personalizada, ya que utilizamos una forma especial de nombrar los issues. Esto sumado al hecho de que los issues los tenemos almacenados en una herramienta propietaria (ni Jira ni Trac+)
Debido a todos estos problemas, decidí ponerme manos a la obra, descargarme el código fuente del plugin y ver si podía solucionarlos.
Luego de investigar y probar, logré solucionar el primer problema, el cual ocurría debido a que en Maven 3, se cambió todo el mecanismo de generación de reportes y manejo de repositorios, haciendo que no se pueda subclasear el repository manager para agregarle nuevas características.
Lo que hice fue modificar la clase ScmActivityReport, e instanciar el repository manager usando el BasicScmManager, ya que no era necesario reemplazar el que provee Maven, ya que el único uso es generar el reporte, y con ese era suficiente.

Instanciación del BasicScmManager
Instanciación del BasicScmManager
En esa clase también aproveché para hacer algunas modificaciones visuales al reporte, como por ejemplo ponerle un border a la tabla, comentar la sección de resumen, hacer que las referencias a los íconos sean a imágenes públicas y poner un título personalizado. 
El segundo paso fue crear un nuevo Grammar, el cual como primer medida, filtra de todos los mensajes de los commits, todos los que tengan el texto "maven-release-plugin", esto es porque no quiero que aparezcan como cambios los commits que haga el plugin de maven, ya que no aportan nada al changelog.
Además aproveché el hecho de tener un nuevo grammar propio, y modifiqué los patrones de búsqueda de issues en el texto del comentario del commit, para que encuentre los issues que yo quería que encuentre.
Para crearse su propio grammar, pueden ver la documentación del plugin, que es bastante simple.
Otra cosa que tuve que hacer, fue tocar la clase SvnScmAdapter y comentar ciertas líneas (104-115) que agregaban como un "release" a los cambios hechos en el trunk. Eso era algo que no necesitaba, ya que lo que yo quería, era apuntar a los tags que crea el Maven Release Plugin.
Finalmente tuve que implementar unos cambios en la clase SvnListConsumer, ya que el filtrado de tags aceptados se hacía antes de agregar un tag ficticio que contiene los cambios hasta antes de la creación del primer tag, lo cual es un problema, ya que lo que yo necesitaba era que se muestren solamente los cambios del tag sobre el cual se hizo el release.

Modificaciones al SvnListConsumer
Modificaciones al SvnListConsumer
De todas maneras solo tenía la primer parte del trabajo realizada hasta este punto. Hasta ahora solo tenía un reporte en html, con el formato de maven, con todos los cambios de la versión que fue liberada en el build actual. Yo lo que quería era que ese reporte se envíe mediante correo electrónico.
Para esto último, estuve investigando, y de todas las opciones disponibles, la que más me gustó fue el Maven Postman Plugin, el cual, lo que hace es enviar un correo electrónico, cuyo contenido es un html presente en el directorio de construcción de nuestro proyecto.
La configuración es simple, y pueden visitar este post, en donde se explican algunos detalles importantes.
El problema, ahora, era que el reporte era generado con el look & feel de los sites de maven, con un menu al costado, etc. Yo quería que el mail enviado sea lo más "limpio" posible.
La solución fue proporcionar un nuevo template, el cual era basado en el template original, y lo que hice, fue eliminar las secciones del header, footer, y menu. Lo que sí, tuve que usar el Maven Dependency Plugin, para empaquetar el template en un artefacto aparte, y que se pueda desempaquetar en todos los proyectos de forma dinámica, y evitar tener que incluirlo dentro de cada proyecto desde el cual yo quiera enviar notificaciones.
Finalmente lo que hice fue modificar el profile "release-profile", el cual es un profile built-in el cual se activa automáticamente al momento de hacer un release. Lo que hice fue agregar las configuraciones de todos los plugins mencionados hasta ahora. Obviamente tuve que compilar mi propia version del ScmChangelogPlugin y deployarla en nuestros servidores privados de binarios. Les paso la configuración final:

 <profile>  
      <id>release-profile</id>  
      <activation>  
           <property>  
                <name>performRelease</name>  
                <value>true</value>  
           </property>  
      </activation>  
      <build>  
           <plugins>  
                <plugin>  
                     <groupId>org.apache.maven.plugins</groupId>  
                     <artifactId>maven-dependency-plugin</artifactId>  
                     <version>2.8</version>  
                     <executions>  
                          <execution>  
                               <id>site</id>  
                               <phase>package</phase>  
                               <goals>  
                                    <goal>unpack</goal>  
                               </goals>  
                               <configuration>  
                                    <artifactItems>  
                                         <artifactItem>  
                                              <groupId>assemblies-comunes</groupId>  
                                              <artifactId>assemblies-comunes</artifactId>  
                                              <version>1.0.0-SNAPSHOT</version>  
                                              <type>jar</type>  
                                              <overWrite>true</overWrite>  
                                              <outputDirectory>${project.build.directory}/unpackedAssemblies</outputDirectory>  
                                              <destFileName>optional-new-name.jar</destFileName>  
                                              <includes>**/*.vm</includes>  
                                         </artifactItem>  
                                    </artifactItems>  
                                    <includes>**/*.vm</includes>  
                                    <outputDirectory>${project.build.directory}/assemblies</outputDirectory>  
                                    <overWriteReleases>false</overWriteReleases>  
                                    <overWriteSnapshots>true</overWriteSnapshots>  
                               </configuration>  
                          </execution>  
                     </executions>  
                </plugin>  
                <plugin>  
                     <groupId>ch.fortysix</groupId>  
                     <artifactId>maven-postman-plugin</artifactId>  
                     <executions>  
                          <execution>  
                               <id>send a mail</id>  
                               <phase>site</phase>  
                               <goals>  
                                    <goal>send-mail</goal>  
                               </goals>  
                               <inherited>true</inherited>  
                               <configuration>  
                                    <from>ciserver@miempresa.com</from>  
                                    <subject>Release exitoso: ${project.artifactId}-${project.version}</subject>  
                                    <failonerror>false</failonerror>  
                                    <mailhost>mail-pruebas.miempresa.com</mailhost>  
                                    <mailuser>user</mailuser>  
                                    <mailpassword>password</mailpassword>  
                                    <htmlMessageFile>target/site/changelog.html</htmlMessageFile>  
                                    <receivers>  
                                         <receiver>Programadores</receiver>  
                                         <receiver>programadores@miempresa.com</receiver>  
                                    </receivers>  
                               </configuration>  
                          </execution>  
                     </executions>  
                </plugin>  
                <plugin>  
                     <groupId>org.apache.maven.plugins</groupId>  
                     <artifactId>maven-site-plugin</artifactId>  
                     <configuration>  
                          <templateDirectory>${basedir}/target/unpackedAssemblies</templateDirectory>  
                          <template>template-changelog.vm</template>  
                     </configuration>  
                </plugin>  
           </plugins>  
      </build>  
      <reporting>  
           <plugins>  
                <plugin>  
                     <groupId>org.codehaus.mojo</groupId>  
                     <artifactId>scmchangelog-maven-plugin</artifactId>  
                     <version>1.4-SNAPSHOT</version>  
                     <configuration>  
                          <trackerUrlPattern>http://miherramientadeissues.miempresa.com?idIssue={0}</trackerUrlPattern>  
                          <trackerType>sourceforge</trackerType>  
                          <grammar>MIGrammar</grammar>  
                          <filter>${project.artifactId}-${project.version}</filter>  
                     </configuration>  
                </plugin>  
           </plugins>  
      </reporting>  
 </profile>  

Fue complejo, pero al final logré lo que quería. Veré si tengo algo de tiempo, en contactarme con los creadores del plugin a ver si se pueden incorporar algunas de las correcciones y mejoras que implementé.
Nos vemos en el proximo post!

Evolución de las versiones de JAVA y .NET a lo largo del tiempo

Timeline JAVA vs DOTNET
Suelo tomar entrevistas a desarrolladores, y una pregunta que solía hacer hace unos años, era que me cuenten las diferencias que había (por ejemplo) entre las versiones de JAVA 1.4 y 5.0. Era un buen ejercicio como para repasar algunas de las características más usadas y además me parecía interesante ver como los candidatos me "presentaban" esas características. Los programadores más experimentados solían poner una cara de "al fin agregaron esto o esto otro", y los que no venían muy bien o no les interesaba, dejaban pasar cosas importantes sin ni siquiera mencionarlas.
Me pasaba algo parecido con la plataforma .NET de Microsoft, no se porque, a mi me pareció siempre interesante ver que cosas nuevas van agregando a los lenguajes y herramientas de trabajo que usamos todos los días a lo largo del tiempo.
Pensando un poco en todo eso, me propuse hacer un repaso de las características más sobresalientes de las dos plataformas, pero para no hacer tan aburrida la cosa, armé un timeline:



Las imágenes son clickeables y agregué en cada release algunas notas acerca de las características más importantes de cada uno.
Opinan que los releases son lo suficientemente frecuentes? Que versión de cada plataforma les pareció más interesante?

Fuente: Wikipedia