Tag Archives: eclipse

Drools channels and Apache Camel integration.

The previous posts only showed how to build a route using the Drools endpoint as the target consumer of the message, but what happen if we need to start the route from a Drools endpoint (the source endpoint) and send a message from the rules consequence to the target endpoint? In this case we need to use Drools channels.

A Drools channel provides a mechanism to send objects from the working memory to some external process or functions.
Continue reading

Advertisements

Como configurar el plugin de Drools Eclipse

Algo muy útil para desarrollar nuestras reglas es utilizar el plugin que nos brinda Drools. Para esto necesitamos tener una version de Eclipse 3.5 (recomendado) o una anterior. Una vez iniciado Eclipse vamos a instalar el plugin, para esto nos dirijimos al menú Help -> Install new software y en este wizard agregamos el repositorio de JBoss Tools

Lo más recomendable, y si querés instalarlo en Eclipse 3.5, es utilizar el repositorio de Development que tiene la siguiente url: http://download.jboss.org/jbosstools/updates/development/ , para update sites de otras versiones entrá acá

Una vez aceptado, seleccionado JBoss Tools y actualizada la información del repositorio, hacemos un filtrado rápido buscando Drools y seleccionamos los plugins que necesitamos (Core, Guvnor y/o Task). Ahora lo único que debemos hacer es seguir los pasos de instalación, aceptar las licencias y reiniciar el workbench.

Una vez reiniciado Eclipse se tiene que configurar el Drools Runtime en las Preferencias de Eclipse. Estos Drools Runtime nos van a permitir ejecutar/debugguear nuestras reglas con distintas versiones de Drools. Lo que tenemos que hacer acá es agregar los distintos runtimes que queramos utilizar en nuestros Drools Project. Tan solo es necesario ingresar un nombre y el path donde están todas las librerías de Drools, o al menos las necesarias para la ejecución/compilación. Que según la documentación oficial son:

* drools-core
* drools-api
* drools-compiler
* antlr3-runtime-3.1.1
* xerces-2.9.1, xml-apis-2.0.2 – only if you are using XML rules, if DRL
only, can skip this.
* eclipse-jdt-core-3.4.2.v_883_R34x – only if you want to compile with
eclipse
* janino-2.5.15 – only if you want to compile with janino

Lo recomendable sería tener configurados al menos dos runtimes, uno con la última versión oficial y otra con la ultima versión estable de desarrollo, que se puede obtener del Hudson https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/

Como último dato, un problema muy común es la aparición de errores al compilarse las reglas con el Drools Builder, esto se debe a que falta agregarse la librería org.eclipse.jdt.core_{$version}.jar, que se encuentra dentro de la carpeta plugins de la instalación de eclipse, como dependencia del proyecto.

Fin del Google Summer of Code 2009

Si, finalmente se terminaron los plazos, se commitearon las modificaciones, se enviaron las evaluaciones y se terminó la codificación de los últimos días en contra del reloj… todo esto hace más de un mes atrás. Esta es una simple actualización, sin video, imagen o diagrama de clases, para tan solo comunicar que mi propossal para JBoss Drools fue terminada y aceptada así que es de esperar errores en el hudson, comportamiento erróneo en el IDE y demás luminarias 😉

Sin dudarlo es una buena experiencia para adentrarse en el mundo del open source, porque seguro que lo posterior que vas a hacer es buscarte tasks en el JIRA (aunque ahora no te paguen, claro)

Drools Eclipse Plugin – Introducción

droolseclipse

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:

https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-introduction/html/ch03.html#d0e1532

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.

plugin1

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.

plugin2

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:

El proyecto esta conformado por varios paquetes que tienen su funcionalidad bien demarcada. Aca pueden ver una pequeña descripcion de algunos de ellos, les dejo el resto para diversión personal:
org.drools.eclipse: Archivos principales del plugin, Clase Activator, Perspective Factory, ImageRegistry de iconos del plugin, constantes para identificación de vistas, etc.
org.drools.eclipse.action: Action de JFace para agregar la funcionalidad de convertir un proyecto Java a un proyecto Drools.
org.drools.eclipse.builder: Clases encargadas de generar los builds de las reglas, marcar los errores en las estructuras internas, etc.
org.drools.eclipse.core: Clases para representar el modelo interno de los componentes del core de Drools, Package, Process, Rule, RuleAttribute, etc.
org.drools.eclipse.core.ui: Clases de tipo LabelProvider, ContentProvider y Sorter’s para los componentes de las vistas de la perspectiva, que permiten asociar objetos con información a widgets.
org.drools.eclipse.dsl.editor: La funcionalidad del editor de DSL y sus componentes para el contenido de Label y Content.
org.drools.eclipse.dsl.editor.completion: Una unica clase encargada de agregar la funcionalidad de autocompletado en la creacion de DSL.
org.drools.flow: Este es uno de los paquetes mas complejos. Contiene toda la funcionalidad y componentes para la creación de los RuleFlow. En una futura entrega seguramente vamos a diseccionar un poco más en profundidad toda su estructura.
org.drools.eclipse.preferences: Se encuentran las distintas preferences pages que se integrarán con las Preferences de Eclipse.
org.drools.eclipse.wizard: Los distintos wizards utilizados en el plugin, unas simples clases Java que extienden de WizardPage o WizardNewCreationFilePage y obtienen el comportamiento de los tipicos wizards de Eclipse.
org.drools.eclipse.view.rules: Contiene la clase encargada de crear la vista de Rules, la cual mostrará todas las reglas existentes en los proyectos abiertos en forma de árbol.
org.drools.reteoo: Contiene todas las clases necesarias para poder dibujar con Draw2D la red RETE de las reglas dentro de la vista ReteViewer en org.drools.eclipse.editors.rete

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.

drools-ide-compilation

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.

drlinfo

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/JFace

have fun

Post original de lucazamador.wordpress.com