Java – Maven o Gradle

noviembre 4, 2014

Maven

Maven es una herramienta de software para la gestión y construcción de proyectos Java –Wikipedia

Gradle

Gradle es una herramienta de automatización de proyecto que se basa en los conceptos de Apache Ant y Maven e introduce un lenguaje específico de dominio (DSL) basado en Groovy en lugar de la forma más tradicional de declarar la configuración del proyecto con XML.
Gradle fue diseñado para una solución multi-proyecto que puede llegar a ser bastante grande, y es compatible con compilaciones incrementales que determina inteligentemente qué partes del árbol de construcción han sido actualizadas, por lo que ninguna tarea dependendiente va a ser re-ejecutada. –Wikipedia

Hasta ahora había utilizado Maven como herramienta de gestión de proyectos, pero la siguiente afirmación me ha hecho pensar en utilizar Gradle para los nuevos proyectos

Google adopted Gradle as the default build tool for the Android OS –technologyconversations.com

Fuentes:
http://technologyconversations.com/2014/06/18/build-tools/

Apache CXF – Ejemplo de firma de un documento XML

Los beneficios de firmar digitalmente un documento XML en nuestros servicios web son que nos provee autenticación, integridad de los datos y el no repudio de la fuente que invoca el servicio.

Para ver un ejemplo de cómo puedes configurar Apache CXF para que utilice y verifique las firmas en un servicio web, sigue el enlace.

via Adding X.509 security headers to Apache CXF SOAP calls | Glen Mazza’s Weblog.

Para configurar Apache CXF en una aplicación web, lo puedes hacer de muchas formas. Esto me confunde, ya que hay distintos ejemplos en internet.

Mi forma preferida es configurar un servlet en el archivo web.xml y configurar los servicios en un archivo beans.xml. Un ejemplo básico de estos archivos sería como el siguiente:

web.xml


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
<servlet>
<servlet-name>CXFServlet</servlet-name>
<display-name>CXF Servlet</display-name>
<servlet-class>
org.apache.cxf.transport.servlet.CXFServlet
</servlet-class>
<init-param>
<param-name>config-location</param-name>
<param-value>/WEB-INF/beans.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>CXFServlet</servlet-name>
<url-pattern>/api/*</url-pattern>
</servlet-mapping>
</web-app>

beans.xml


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jaxws="http://cxf.apache.org/jaxws" xmlns:jaxrs="http://cxf.apache.org/jaxrs"
xmlns="http://www.springframework.org/schema/beans"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd
http://cxf.apache.org/jaxrs
http://cxf.apache.org/schemas/jaxrs.xsd">

<import resource="classpath:META-INF/cxf/cxf.xml" />

<jaxws:endpoint id="HelloSOAP" address="/ws/helloService"
implementor="com.acme.ws.soap.HelloServiceImpl" />

<jaxrs:server id="rest-api" address="/rest">
<jaxrs:serviceBeans>
<bean id="HelloREST" class="com.acme.ws.rest.HelloREST" />
</jaxrs:serviceBeans>
</jaxrs:server>

</beans>

Las dependencias necesarias en Maven son las siguientes:


<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxrs</artifactId>
<version>2.7.0</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>2.7.0</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>3.0.6.RELEASE</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.6.6</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.6.6</version>
</dependency>

La dependencia a la librería spring-web es necesaria desde la versión 2.6 de Apache CXF. Las dependencias de SLF4J son opcionales, pero muy recomendables para ver la información del Log. Si quieres saber como configurar SLF4J puedes verlo aquí.

Fuentes:
Apache CXF — Servlet Transport.
http://stackoverflow.com/questions/6349424/apache-cxf-rs-extensions-issue-in-2-4-0

Para saber cuáles son las ventajas y desventajas entre un formato y otro, puedes ver la siguiente discusión

http://stackoverflow.com/questions/1256835/why-chose-xml-over-properties-files-for-log4j-configuration

Desde mi punto de vista, deberíamos usar el formato XML.

Aquí dejo un ejemplo de un archivo de configuración properties y su equivalente en xml que encontré en esta página.

log4j.properties

# Set root logger level to DEBUG and its only appender to A1.
log4j.rootLogger=DEBUG, A1

# A1 is set to be a ConsoleAppender.
log4j.appender.A1=org.apache.log4j.ConsoleAppender

# A1 uses PatternLayout.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

log4j.xml

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">

<!-- A1 is set to be a ConsoleAppender -->
 <appender name="A1" class="org.apache.log4j.ConsoleAppender">
 <!-- A1 uses PatternLayout -->
 <layout class="org.apache.log4j.PatternLayout">
 <param name="ConversionPattern" value="%-4r [%t] %-5p %c %x - %m%n"/>
 </layout>
 </appender>

<root>
 <!-- Set root logger level to DEBUG and its only appender to A1 -->
 <priority value ="debug" />
 <appender-ref ref="A1" />
 </root>

</log4j:configuration>

Si desarrollas aplicaciones web seguramente utilizas Firebug para analizar los envíos y respuestas del servidor. Pero hay ocasiones que necesitas hacer una prueba de un servicio REST al que sólo es necesario enviar un bloque de información, podría ser un fragmento JSON o XML. Pues a la fecha no es posible hacer esto con firebug, así que necesitamos otra herramienta que nos permita hacer esto. En Linux podemos hacerlo fácilmente mediante el comando curl, pero es más fácil hacerlo desde una interfaz gráfica como la extensión para Firefox RESTClient.

En un proyecto de SmartGwt me aparecía un mensaje de error que decía:

Content is not allowed in Prolog

Queeeeeeee…. yo ni siquiera utilizo Prolog :@

Bueno, pues se debe a que SmartClient tiene archivos con extensión XML que no son en realidad XML -parecieran mas bien JSON– que son copiados a la carpeta de nuestro modulo al momento de compilar. Por default no aparecen estos errores sino hasta que, accidentalmente en mi caso, das clic derecho en la carpeta y seleccionas “Validate”.

Para deshacerte de estos molestos mensajes de error basta con borrar la carpeta. No te preocupes, volvera a ser generada por el compilador.
Si no quieres eliminarla, tu sabrás porque, puedes dar clic derecho en la carpeta y seleccionar la opción “Properties”, luego en “Resource” desmarca la casilla que dice “Executable”. No se para que se utiliza esa opción pero los mensajes de error ya no aparecerán.

Update(2011-17-10)

También podemos desactivar la validación de archivos XML creando un filtro. Intenté crear el filtro sólo para la carpeta “sc/schema”, e incluso para los archivos con extensión “.ds.xml”, pero fue en vano. Eclipse no permite el uso de expresiones -regex o comodines- en los filtros. El único filtro que me fue de utilidad es el de la naturaleza del proyecto.

Accede al menú “Window->Preferences” y da clic en “Validation”, busca la entrada “XML validator” y da clic en los puntos suspensivos -en la columna “Settings”-

Selecciona el grupo “Exclude Group” y da clic en el botón “Add Rule…” y selecciona el tipo “Project Nature”

Selecciona la naturaleza “GWT Nature – com.google.gwt.eclipse.core.gwtNature” de la lista y da clic en “Finish”

Acepta los valores ingresados y cuando te pregunte si deseas hacer un “full rebuild” di que si.

Fuentes:
SmartGwt Forum


Una caracteristica indispensable -hoy en día- de cualquier editor de código (C#, Java, XML, etc) es el autocompletado.
Pues de repente, esta característica dejo de funcionar en mi Eclipse. El problema fue que al instalar los plugins de Aptana -necesario si vas a desarrollar aplicaciones para WebOS- se sobreescribió el editor por default de los archivos XML por el de Aptana, el cual no tiene esta funcionalidad. Para que regrese el autocompletado basta dar clic derecho en el archivo XML y seleccionar “abrir con->editor XML”. De aquí en adelante este será el editor que se use por default cuando abramos un archivo XML.

Fuente:
mkyong.com