Showing posts with label maven. Show all posts
Showing posts with label maven. Show all posts

27 October 2012

Eclipse, Maven, Tomcat y Spring : ClassNotFoundException org.springframework.web.context.ContextLoaderListener

Descripción:

Desarrollando una aplicación con Eclipse, Maven, Spring .... al intentar iniciar el servidor tomcat desde el propio Eclipse al principio suele salir el siguiente fallo:
27-oct-2012 10:49:47 org.apache.catalina.core.StandardContext listenerStart
GRAVE: Error configurando escuchador de aplicación de clase 
org.springframework.web.context.ContextLoaderListener
java.lang.ClassNotFoundException: 
org.springframework.web.context.ContextLoaderListener
 at org.apache.catalina.loader.WebappClassLoader.loadClass
(WebappClassLoader.java:1680)


Solución:
En las propiedades del proyecto hay que ir al apartado "Deployment Assembly" y corregir el listado de recursos para que añada los del classpath de maven.


- FIN -

21 December 2011

Eclipse Maven : Did you package/install active project artifact

[INFO] Copying artifact[ejb:com.cliente.proyecto.ejb:ejbNegocio:1.5-SNAPSHOT] to[EJBNegocio.jar]
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Cannot copy a directory: D:\desarrollo\proyectos\proyecto\branch\testweb\target\classes; Did you package/install active project artifact:
artifact = active project artifact:
artifact = com.cliente.proyecto:testweb:war:1.5-SNAPSHOT:compile;
project: MavenProject: com.cliente.proyecto:testweb:1.5-SNAPSHOT @ D:\desarrollo\proyectos\proyecto\branch\testweb\pom.xml;
project: MavenProject: com.cliente.proyecto:testweb:1.5-SNAPSHOT @ D:\desarrollo\proyectos\proyecto\branch\testweb\pom.xml?
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------

El problema:

La solución: Desactivar la casilla marcada.

- FIN -

28 November 2011

Project configuration is not up-to-date with pom.xml

Problema:
Project configuration is not up-to-date with pom.xml. Run project configuration update.

Solución:
Teniendo el plugin de maven instalado en eclipse, boton derecho sobre el proyecto en cuestión y:




- FIN -

24 March 2011

Desplegando con diferentes ficheros de configuración usando profiles y resources

Hace poco puse unos apuntes a cerca de como desplegar usando diferentes ficheros de configuración, dependiendo del entorno de despliegue; digamos que ahora explicaré lo mismo pero de otra forma, para complacer a aquellos puristas de maven :-)

A continuación se expondrán tres grandes secciones de como hacer esto:
  1. La definición de que archivos copiar y excluir
  2. La configuración del plugin Maven Resources
  3. La definición de profiles

La definición de que archivos copiar y excluir
La escencia básicamente es copiar unos determinados recursos y excluir otros; y la forma de indicar esto es utilizando el tag resources dentro del tag build, donde en la invocación se utilice una propiedad que indique que recursos incluir.

<build>
  ...
  <resources>
    <resource>
        <directory>src/main/resources</directory>
          <includes>
              <include>**.*</include>
              <include>custom/${deploy.target.folder}/**.*</include>
          </includes>
        <excludes>
            <exclude>custom/**.*</exclude>
        </excludes>
    </resource>
  </resources>
  ...

En el snippet anterior, por defecto se excluyen todos los ficheros dentro del directorio src/main/resources/custom, pero se incluyen todos los ficheros de la carpeta src/main/resources y src/main/resources/custom/${deploy.target.folder}, donde la propiedad deploy.target.folder indica la subcarpeta, de cuyo contenido si que hay que incluir; los posibles valores para esta propiedad se informarán desde los perfiles maven creados para cada entorno destino.

La configuración del plugin Maven Resources
Ahora queda controlar la copia de los recursos del proyecto al directorio destino de la generación del ejecutable; para ello disponemos del goal resources:copy-resources perteneciente al plugin Maven Resources.

<build>
  ...
  ...resources...
  ...
   <plugins>
      <plugin>
        <artifactId>maven-resources-plugin</artifactId>
        <version>2.4.3</version>
        <executions>
          <execution>
            <id>copy-resources</id>
            <phase>validate</phase>
            <goals>
              <goal>copy-resources</goal>
            </goals>
            <configuration>
              <outputDirectory>${project.build.directory}/${project.build.finalName}/images</outputDirectory>
              <resources>
                <resource>
                  <directory>src/main/resources/custom/${deploy.target.folder}/images</directory>
                </resource>
              </resources>
            </configuration>
          </execution>
        </executions>
      </plugin>

    </plugins>

La definición de profiles
Ahora solo queda definir los perfiles, uno para cada entorno de despliegue.
...
  <profiles>
    <profile>
      <id>integracion</id>
      <properties>
        <deploy.target.folder>int</deploy.target.folder>
      </properties>
    </profile>
    <profile>
      <id>pre-produccion</id>
      <properties>
        <deploy.target.folder>pre</deploy.target.folder>
      </properties>
    </profile>
    <profile>
      <id>produccion</id>
      <properties>
        <deploy.target.folder>pro</deploy.target.folder>
      </properties>
    </profile>    
  </profiles>
  ...

No esta demás decir que en nuestro proyecto tendremos que disponer de los directorios:
  • src/main/resources/custom/int
  • src/main/resources/custom/pre
  • src/main/resources/custom/pro

Y que en cada uno de estos directorios existen los mismos recursos ;-).

Bueno este artículo a sido fruto de la colaboración de Jordi Carbonell.

Enlaces relacionados:

- FIN -

17 October 2010

m2eclipse unable to resolve parent pom

El plugin m2eclipse de eclipse a veces suele dar un mensaje de error en la primera linea del fichero pom.xml, con el mensaje "... unable to resolve parent pom ...".

En mi caso sucede cada vez que apunto un proyecto a una nueva versión de su parent POM, que aún no ha sido instalado en mi respositorio local, pero si existe en el repositorio nexus del que dispongo, y que por tanto se descarga en la siguiente compilación del artefacto.

La explicación según figura en el JIRA de Sonatype es que este plugin no re-indexa correctamente los índices de los artefactos descargados al vuelo, por tanto si el mensaje molesta, la solución, es simplemente reiniciar eclipse para que se actualicen los índices; y puedo dar fe que funciona :-)


- FIN -

11 October 2010

Llegó Maven 3.0

El pasado 8 de Octubre se libero Maven 3.0, al parecer con grandes cambios y algunas novedades, como por ejemplo Tycho, los planes para m2eclipse, maven shell, polyglot maven y los planes sobre que hacer al rededor del servidor de integración continua Hudson.

Para aquellos que esten preocupados en la compatibilidad con maven 2, los chicos de apache también han publicado una matriz de compatibilidad, entre los cuales se ven afectados:
  • El uso de profiles
  • El uso del plugin site y de reporting
  • Mejoras en el uso de red
  • Validación estricta del fichero POM
He aquí también la matriz de compatibilidad de plugins con maven 3.x.

Enlaces relacionados:
- FIN -

28 September 2010

Desplegando con diferentes ficheros de configuración

Continuando con la cruzada maven + liferay....

Bueno, muchas veces, cuando desarrollamos, atacamos nuestra propia base de datos y utilizamos ficheros de propiedades para almacenar algunos de los parametros variables de la aplicación, evidentemente con las rutas y puertos de nuestra máquina; ahora bien, cuando desplegamos nuestra aplicación, en otro entorno que no sea el de desarrollo local, se nos presenta el problema de tener que modificar el paquete (jar, war, ear), con el fin de actualizar los valores de las propiedades, con aquellos correspondientes al entorno de destino.

Esto es algo que se puede controlar fácilmente, si utilizamos ANT o MAVEN.  En el caso de MAVEN, este dispone de un elemento llamado PROFILE y de un plugin llamado maven-antrun-plugin, cuya combinación nos permite generar los desplegables adecuados al entorno de destino de una forma fácil.

Pues bien el secreto de la receta se basa en:
  1. Tener tantos ficheros de propiedades como entornos de destino vayamos a tener ( config.properties, config.int.properties, config.pre.properties, config.pro.properties)
  2. Crear un perfil, por cada entorno de destino previsto, dentro de nuestro pom.xml, de preferencia con un nombre descritptivo, referente a su destino.
  3. Añadir el plugin maven-antrun-plugin en cada perfil para que borre los ficheros redundantes de configuración, y copie y renombre los necesarios.

He aquí un pequeño snippet de ejemplo, con "dos ficheros y un destino":

<profiles>
 ...
 <profile>
  <id>integracion</id>
  <build>
    <plugins>
       ...
 <plugin>
  <artifactId>maven-antrun-plugin</artifactId>
  <executions>
   <execution>
    <phase>compile</phase>
    <goals><goal>run</goal></goals>
 
    <configuration>
     <tasks>
      <echo>------------------------------------------------</echo>
      <echo>COPIANDO LOS FICHEROS DEL ENTORNO DE INTEGRACION</echo>
      <echo>------------------------------------------------</echo>
      <delete
       file="${project.build.outputDirectory}/config.int.properties" />
      <delete
       file="${project.build.outputDirectory}/config.properties" />
      <copy
       file="src/main/resources/config.int.properties"
       tofile="${project.build.outputDirectory}/config.properties" />
     </tasks>
    </configuration>
    
   </execution>
  </executions>
 </plugin>
       ...
    </plugins>
  </build>
 </profile>
 ...
</profiles>

En este ejemplo, en un entorno normal se utilizará el fichero config.properties por defecto, y cuando invocamos la compilación y la generación del war no se hará nada especial.
Sin embargo, si, al compilar y generar el war indicamos que se debe ejecutar el perfil llamado "integracion", este borrará todos los ficheros de configuración de los entornos innecesarios y copiará únicamente aquel que necesita, renombrandolo a fin que pueda ser accedido por el código, en tiempo de ejecución, sin más complicaciones.

InputStream is = Configuracion.class.getResourceAsStream("config.properties");
Properties tmp = new Properties();
tmp.load(is);
Evidentemente a este último código le falta algún que otro try/catch.


Enlaces relacionados:
Building For Different Environments with Maven 2


- FIN -

09 September 2010

Provider com.bea.xml.stream.MXParserFactory not found

Probando la creación de usuarios en liferay, utilizando su API, con test unitarios utilizando junit, me ha salido el mensaje de error:
javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found
Esto se soluciona añadiendo la dependencia a la libreria stax 1.1.2-dev, la cual se encuentra en los repositorios públicos de maven; curiosamente al incluir la dependencia, al compilar me pide el artefacto xmlbeans-jsr173-api, el cual no logre encontrar en los repositorios :-((

[INFO] -----------------------------------
[ERROR] BUILD ERROR
[INFO] -----------------------------------
[INFO] Failed to resolve artifact.

Missing:
----------
1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev
Dado este problema la solución es utilizar las exclusiones de dependencias que proporciona maven, quedando la inclusión de la dependencia de la siguiente manera.

<dependency>
   <groupId>stax</groupId>
   <artifactId>stax</artifactId>
   <version>1.1.2-dev</version>
   <scope>test</scope>
   <exclusions>
      <exclusion>
         <artifactId>xmlbeans-jsr173-api</artifactId>
         <groupId>xmlbeans</groupId>
      <exclusion>
   <exclusions>  
<dependency>

- FIN -

30 July 2010

Creación de portlets con Struts2, Maven y Eclipse

Struts2 nos provee de una serie de arquetipos maven que aceleran nuestro proceso de desarrollo, algunos de ellos nos permiten crear portlets JSR 168.

Los arquetipos para crear portlets JSR 168 son:
  • struts2-archetype-portlet.- Para crear un portlets vacios.
  • struts2-archetype-dbportlet.- Para crear portlets que muestran el contenido de una tabla de base de datos (Consultas, Spring, HSQL, preferencias).

Para tener disponibles estos arquetipos en el repositorio maven al que esta conectado eclipse hay que añadir un arquetipo nuevo; esta opción sale cuando creamos un proyecto maven y nos pide que seleccionemos el arquetipo que deseamos utilizar.


Una vez que se levanta el popup del nuevo arquetipo, hay que introducir sus opciones de registro del arquetipo que deseamos utilizar.

Si estamos creando portlets para Liferay, después de crear el proyecto, simplemente hay que añadir los ficheros propios de configuración de este (liferay-display.xml, liferay-plugin-package.properties y liferay-portlet.xml).

Enlaces relacionados:


- FIN -

21 June 2010

Error creando un tema (theme) liferay con maven

Hoy me he puesto a crear un tema(theme) de liferay con
azzazzel-liferay-maven-sdk, y al contrario que, cuando, se crean portlets y hooks da el siguiente fallo.

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------
[INFO] Building Maven Liferay Theme Archetype
[INFO]    task-segment: [package]
[INFO] ------------------------------------------------------
[INFO] ------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------
[INFO] Failed to resolve artifact.

Missing:
----------
1) com.sun:tools:jar:1.4.2

  Try downloading the file manually from the project website.

  Then, install it using the command: 
      mvn install:install-file -DgroupId=com.sun -DartifactId=tools -Dversion=1.4.2 -Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
      mvn deploy:deploy-file -DgroupId=com.sun -DartifactId=tools -Dversion=1.4.2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
   1) com.commsen.liferay:liferay-maven-plugin:maven-plugin:5.2.3-r2
   2) com.sun:tools:jar:1.4.2

----------
1 required artifact is missing.

for artifact: 
  com.commsen.liferay:liferay-maven-plugin:maven-plugin:5.2.3-r2

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)



[INFO] ------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------
[INFO] Total time: 5 seconds
[INFO] Finished at: Mon Jun 21 10:24:38 CEST 2010
[INFO] Final Memory: 9M/17M
[INFO] ------------------------------------------------------


Un colega se encontro el otro día este mismo problema; y este consiste en que el artefacto liferay-maven-plugin-5.2.3-r2 tiene una dependencia al fichero tools.jar

Inspeccionando el pom de este artefacto en el repositorio local de maven, cai en que este apuntaba a la dependencia de la versión 1.4.2 de java, y que mi JAVA_HOME apunta a la versión 1.5.0_06

SOLUCIÓN:
Cambiar el pom.xml de liferay-maven-plugin para que el tools.jar sea la de la versión 5.

<dependency>
 <groupId>com.sun</groupId>
 <artifactId>tools</artifactId>
 <version>1.5.0_06</version>
 <scope>system</scope>
 <systemPath>
         ${java.home}/../lib/tools.jar
 </systemPath>
</dependency>

Enlaces relacionados:
Creating Liferay Themes

- FIN -

16 June 2010

Desplegar un "portlet maven" en la carpeta deploy de liferay

Desde luego desarrollar portlets o hooks liferay, utilizando eclipse con maven tiene sus ventajas (hay material para muchos post), pero uno de los contratiempos que encuentro es tener que copiar el war resultante del empaquetado, en la carpeta deploy de liferay.

Pero a grandes males, grandes remedios; así que solo tenemos que configurar el pom.xml para indicarle a maven que el directorio de salida donde se depositará el war sea la carpeta deploy de liferay.

He aquí el extracto del pom.xml que hace esto.

...
<packaging>war</packaging>
...
<build>
...
 <plugin>
  <!-- http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html  -->
  <artifactId>maven-war-plugin</artifactid>
  <configuration>
  <outputDirectory>C:/dev/liferay/deploy</outputdirectory>
  </configuration>
 </plugin>
...
</build>
...


Buen provecho!

Enlaces relacionados:
Creating Liferay portlet with liferay-maven-sdk

- FIN -

22 February 2010

Probando JRebel con Maven, Spring, Netbeans y Glassfish

La combinación de Maven, Spring, Netbeans y Glassfish nos permite crear aplicaciones potentes en cuanto a buenas prácticas, gestión y construcción del proyecto, con un IDE ampliamente utilizado y conocido, sobre un servidor de aplicaciones decente... hasta aquí todo esta muy bien.

Lo malo, son los cambios que se experimentan durante la fase de desarrollo.

Lo normal en la construcción de una aplicación JEE es que este compuesta por distintos componentes, como por ejemplo:
  • 1 jar con los componentes comunes
  • 1 jar con los objetos del dominio
  • 1 jar con los DAO
  • 1 jar con el negocio de pepito :-)
  • 1 jar con el negocio de juanito ;-)
  • 1 jar con los clientes de WS de ...
  • 1 jar con ....
  • y finalmente un WAR/EAR

Cualquier cambio que se realize en cualquiera de esos componentes requiere que se compile y despliegue la aplicación al completo en el servidor de aplicaciones, esto incluye el famoso undeploy/deploy de nuestro WAR/EAR, algo que suele ser muy ... pero que muy lento.

JRebel permite evitarnos todo este proceso "traumático", pasando de actualizar el servidor de unos minutos eternos a unos pocos segundos.

El proceso de implantación es el siguiente:
  1. Descargar e instalar JRebel ( 2.2.1 (21st December 2009) )
  2. Configurar Glassfish
  3. Que la aplicacion principal(WAR/EAR) tenga un fichero denominado
    rebel.xml
  4. Probar que funciona

1.- Descargar e instalar JRebel
Obviamente el título lo dice todo : Descarga

2.- Configurar Glassfish v2.1
Se deben añadir dos opciones de arranque a la máquina virtual del servidor de aplicaciones.


"Cuidado con la documentación por que utilizar la barra (\) os puede originar que vuestro Glassfish no arranque (en windows), por ello es mejor utilizar la contra barra (/)"

3.- Configuracion de la aplicacion principal (WAR)
Supiendo que nuestra aplicacion esta ubicada en la carpeta "c:/application", que la aplicacion web se llama "webapp" y que sus compomentes se llamanan "un-componente-jar" y "otro-componente-jar" el fichero de configuración rebel.xml tendría que estar en el directorio classes(en su defecto la raiz del código fuente) de la "webapp"; y quedaría de la siguiente forma:
<?xml version="1.0" encoding="UTF-8"?> 
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.zeroturnaround.com" xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">

<classpath>
   <dir name="C:/application/webapp/src/main/java">
      <include name="**/*.*">
   </dir>
   <dir name="C:/application/webapp/target/classes">
      <include name="**/*.*">
   </dir>

   <dir name="C:/application/webapp/target/classes"></dir>

   <dir name="C:/application/un-componente-jar/target/classes">
      <include name="**/*.*">
   </dir>

   <dir name="C:/application/otro-componente-jar/target/classes">
      <include name="**/*.*">
   </dir>
</classpath>

<web>
   <link target="/">
      <dir name="C:/application/webapp/src/main/webapp"></dir>
   </link>
</web>
</application>
4.- Probar que funciona
Si arrancamos Glassfish en modo debug, podemos cambiar el código de cualquier clase de los jars y simplemente guardandola, JRebel se encarga de actualizarla en el servidor de aplicaciones sin tener que volver a desplegar la webapp.

Enlaces relacionados:

Solo decir que desarrollar asi ya es una delicia por la cantidad de tiempo que uno puede llegar a ahorrar, ahora me queda paciencia para mas cosas :-)

- FIN -