Vamos a ver que se esconde atrás del plugin de Drools, la idea de esta primer entrega es dar una visión general sobre los proyectos, estructuras y tecnologías que componen el plugin de Drools para Eclipse. El plugin esta desarrollado sobre la plataforma RCP Eclipse, utilizando todas las principales features a nivel vista y de interacción que ofrece este framework, además de usar widgets de JFace, las librerías GEF y Draw2D que se utilizan para generar los gráficos de la red RETE que se genera con la creación de las reglas, etc.
Para el proceso de instalación de los fuentes del proyecto, la instalación y compilación del plugin es aconsejable seguir con los pasos que se encuentran en la documentación oficial de Drools:
Una vez realizados los pasos descriptos en la documentación oficial, dentro de tu copia local del svn de Drools vas a encontrar la carpeta drools-eclipse, la cual contiene todos los proyectos que componen el Drools IDE. Separados en sus correspondientes carpetas podes encontrar todos los archivos que componen al plugin de Drools para Eclipse (org.drools.eclipse), asi como los archivos de testing del plugin, el plugin de Guvnor para Eclipse (org.guvnor.tools), sus archivos de testing, asi como todos los Feature Proyects de estos distintos proyectos (org.guvnor.tools.feature, org.drools.eclipse.feature), y mas proyectos que no son de demasiada relevancia en este primer acercamiento.
Como te habrás dado cuenta, el proyecto que nos interesa en el que contiene toda la funcionalidad del plugin, o sea org.drools.eclipse. Como partida podemos decir que la columna vertical de un plugin de Eclipse esta dado por el archivo de configuración plugin.xml, en el cual tenemos que definir ciertos comportamientos iniciales del plugin y los que nosotros necesitemos agregarle. Este archivo se puede editar de forma tediosa en un editor de texto, o con un Plug-in Manifest Editor que traen los Eclipse con el Plugin Development Enviroment instalado.
En este editor se definen parametros importantes como el id, la clase Activator (en este caso org.drools.eclipse.DroolsEclipsePlugin, la cual funciona como la clase principal del plugin y como misma tiene bastante comportamiento y datos de las reglas), los plugins que necesita el plugin para funcionar, el classpath del plugin (el cual es diferente al del proyecto), la integración de la funcionalidad del plugin con los componentes del Eclipse, etc. Esto ultimo se hace dentro del apartado/solapa Extensions, en el cual se define la integración de las Property Pages creadas con las Properties de Eclipse, los nuevos wizards, la nueva perspectiva Drools, los nuevos editores que se utilizaran para los DRL/DSL, los builders que se encargaran de compilar las reglas y marcar los errores existentes, etc.
Uno de los extension point principales, y estandar en todos los plugins, es org.eclipse.ui.perspectives, en el que se define cual será la clase que implementará la Perspective Factory del plugin y definirá cuales seran las vistas y su disposición dentro de la perspectiva Drools, ademas de definir el id, el nombre de la misma y el ícono. El workbench del Eclipse será el encargado de ejecutar el método createInitialLayout() que tiene toda la información sobre la disposicion de las views y los PlaceHolder en los correspondientes Page Layout, que definen las distintas “secciones” de una perspectiva.
Paquetes del proyecto:
Si estuvieron revisando el código fuente se pudieron dar cuenta que la cantidad de paquetes que compone este proyecto es considerablemente grande y compleja. Pero dejemos de lado el código Java un rato y veamos que otros archivos compone el plugin. Dentro del proyecto podemos encontrar lo siguiente:
resources: Archivos que se usan como Template por los wizards del plugin, archivos de texto con keywords JAVA/MVEL que se usarán para resaltar la sintaxis de las reglas dentro de los editores y archivos de configuración del ContentAssist.
icons: Esta carpeta contiene los iconos utilizados por todo el plugin, los cuales son cacheados dentro de un ImageRegistry para un acceso mas rápido, y también los distintos skins que se pueden utilizar con la funcionalidad de BPMN de Drools 5.
build.properties: Contiene la información de los archivos que formarán parte de la creación del plugin, es la misma información que se puede acceder desde el Plug-in Manifest Editor de manera mas amigable.
MANIFEST.MF: Este archivo contiene la información sobre la identificación del plugin, su classpath, sus dependencias y el modo de carga de las mismas, entre otras. También es la misma información que puede visualizarse desde el PME.
Proceso de compilación de las reglas
Metiendo la narices en algo más interesante, el siguiente gráfico muestra el proceso resumido de compilación de reglas que realiza el plugin utilizando los ProjectBuilder que brinda el framework de Eclipse. El proceso de compilación se realiza automáticamente cuando se guardan las modificaciones de las reglas en el DRL editor.
A grandes rasgos, la funcionalidad de la clase DroolsEclipsePlugin es la de mantener las referencias a las reglas parseadas, y la caché de la compilación de todas las reglas existentes en todos los Drools Projects abiertos en el workspace, según lo seleccionado en las Preferencias del IDE. Toda la información sobre las reglas se guardan en objetos del tipo org.drools.eclipse.DRLInfo, que contiene información como el sourcePathName, el PackageDescr, el Package, los DroolsErrors, etc.
Si estuviste trabajando con Drools seguramente reconociste algunas de las clases que componen el DRLInfo. En este primer acercamiento no tiene mucho sentido profundizar más, así que en un próximo post voy a explicar mas profundidad como funciona el proceso de compilación y como hace el plugin para generar el cache de reglas compiladas, la asociación de un DroolsBuilder a un proyecto, la funcionalidad de un DRLInfo y más información interesante para poder desarrollar nuevas funcionalidades al Drools IDE.
Para poder hacer esto es necesario tener ciertos conocimientos de toda la tecnología involucrada en el IDE, más que nada del framework RCP que es el que más se utiliza en todo el proyecto.
http://wiki.eclipse.org/index.php/Rich_Client_Platform http://wiki.eclipse.org/index.php/JFacehave fun
Post original de lucazamador.wordpress.com
lucazamador.wordpress.com 