Uso Eclipse, WTP (Web Tools Project) y Maven desde hace mucho años. Cada vez que he tenido que configurar un nuevo entorno, y han pasado meses desde la última vez, me encuentro con pequeñas sorpresas. Por otro lado es normal, en los proyectos se toman decisiones que afectan a quienes usamos el software. Además en este caso todas las piezas son open source y es una maravilla que podamos disfrutar de estas herramientas sin un coste directo.
Desde hace unos días estoy montando mi entorno de desarrollo en un nuevo MacBook Pro que he adquirido. Instalé Eclipse Helios, Apache Maven 2.2.1 (sí, aun tenemos proyectos no migrados) y algunos plugins para Eclipse como MultiProject, Checkstyle, AnyEdit, etc.
Cual fue mi sorpresa que tras realizar el checkout de mivecindad, ejecutar mvn install eclipse:eclipse [...] e intentar ejecutar el proyecto (Facet: Dynamic Web Module, Java) había muchas dependencias que WTP no podía resolver. Esto se solucionaba anteriormente indicándole a proyecto principal (webapp) que los otros proyectos (service, model, resources, etc) eran módulos (J2EE Modules) de éste. Para ello encontrábamos una opción en las preferencias del proyecto llamada J2EE Modules Dependencies.
Pues bien, esta opción ha desaparecido. Ahora podemos hacer lo mismo dentro de la opción Deployment Assembly.
Si tus ingredientes son: Eclipse, Web Tool Platform (WTP), m2eclipse y un proyecto modelado con maven y con varios módulos, quizás te has encontrado con el problema de que tu aplicación web no se lanza correctamente. Usando m2eclipse puedes importar tu proyecto maven a Eclipse creando un proyecto para cada uno de los módulos. Uno de ellos corresponderá con tu webapp, en mi caso opina-webapp.

Es probable que cuando lances tu aplicación con WTP (p.e. con Apache Tomcat) no se encuentren las librerías y salten excepciones ClassNotFound. Esto se debe a que el proyecto Eclipse que contiene tu aplicación web (webapp) no está incluyendo (en tiempo de ejecución) las librerías que tu has definido previamente como dependencias del proyecto. Para resolver esto, accedemos a las propiedades del proyecto (webapp), J2EE Modules Dependencies y seleccionados:
- Maven Dependencies (declaradas en el POM de este módulo, más las heredadas del POM padre).
- En mi caso además tuve que incluir:
- opina-model (modelo de datos)
- opina-dao (capa de acceso a datos)

Ahí queda esta nota por si a alguien le pasa. Supongo que si me hubiera leído documentación de m2eclipse esto no me hubiera pasado.
Recientemente he tenido que configurar un entorno de desarrollo para trabajar con Drupal en Linux, concretamente Madriva. Quizás a alguien le puedan venir bien estas notas:
- Instalar y configurar Eclipse IDE con soporte para PHP (PDT Project). Ya comenté hace tiempo que uso Pulse para gestionar y mantener distintas instancias de Eclipse IDE.
- Instalamos Apache Web Server con soporte para PHP (preferiblemente PHP5). Para esto tenemos varias opciones:
- LAMPStack de BitNami
- Seguir estas instrucciones.
- Instalar Apache Web Server con soporte para PHP y MySQL desde paquetes
- Instalar Apache Web Server con soporte para PHP y MySQL desde los fuentes
- Descargamos y descomprimimos Drupal dentro de nuestro workspace de Eclipse:
[recena@localhost Eclipse 3.3 PDT]$ wget http://ftp.drupal.org/files/projects/drupal-6.4.tar.gz
[recena@localhost Eclipse 3.3 PDT]$ tar -xvzf drupal-6.4.tar.gz
[recena@localhost Eclipse 3.3 PDT]$ rm drupal-6.4.tar.gz
- Ahora configuramos un alias (p.e. qabox) para poder acceder a nuestra instalación de Drupal de una forma similar a http://localhost/qabox. Para ello añadimos a httpd.conf:
Alias /qabox "/home/recena/Workspaces/Eclipse 3.3 PDT/drupal-6.4"
<Directory "/home/recena/Workspaces/Eclipse 3.3 PDT/drupal-6.4">
AllowOverride All
Options MultiViews Indexes Includes FollowSymLinks
Order allow,deny
Allow from all
</Directory>
- A partir de este momento, accedemos a http://localhost/qabox, y lo que resta es seguir las instrucciones de la propia instalación de Drupal. Que no se os olvide colocar el correspondiente archivo .htaccess en el directorio raíz donde se encuentre instalado Drupal. En la documentación viene todo perfectamente comentado.
Una vez que tenemos lo básico para ejecutar Drupal nuestro trabajo se centrará -probablemente- en el desarrollo de módulos y/o temas. Pues bien, la idea es tener un proyecto para cada uno de los módulos y/o temas que desarrollemos. De esta forma tendremos nuestra instalación de Drupal por un lado, y nuestros desarrollos (modelados como proyectos de Eclipse) por otro. Ahora lo único que tenemos que hacer es decirle a Drupal que use estos módulos y/o temas. Así iremos viendo los resultados. Para hacer esto basta con hacer simples enlaces simbólicos donde corresponde y hacía donde se encuentran nuestros proyectos.
En la captura de pantalla que se muestra a continuación, veréis un tema que estoy desarrollando que se llama QABox y el enlace simbólico que he creado para que Drupal sepa que dispone de ese tema como se estuviera almacenado en $DRUPAL_HOME/sites/default/themes (p.e.):

Recent Comments