External artifact building

We already know that we can use Guvnor to build packages externally. In this section we'll look how to do it with a build tool called Ant. We can then easily add an artifact compilation step into our existing build process that we may have.

Note that in future versions the Drools team is planning to add support for Maven as well. If you're running Maven, as a workaround it is possible to call an Ant task from within a Maven build.

Building with Ant

Apache Ant is a general-purpose building tool. More information about Ant can be found at http://ant.apache.org/. Module drools-ant, from the droolsjbpm-tools-distribution-5.5.0.Final.zip downloadable file contains an Ant task for building Drools artifacts. We'll build the validation knowledge base from Chapter 3, Validating, using this Ant task.

All information required by Ant will be stored in a file called build.xml. We'll now go step-by-step through this file. It starts with a project definition:

<?xml version="1.0" encoding="UTF-8" ?>
<project default="compileArtifacts">
  <property name="projectPath" value="" />
  <property name="droolsPath" value="drools_lib" />

Code listing 3: The build.xml file – project definition (part 1/4)

As it is usual with Ant build files, the project definition contains a default Ant target that will be called when no target is specified. This default target is called compileArtifacts. The next two lines define two properties, projectPath and droolsPath, that we'll be using. The first property is a path to the current project, and the second is a path to Drools libraries.

The next code listing will define Drools libraries that will be needed:

  <path id="drools.classpath">
    <pathelement location="${droolsPath}/drools-ant.jar" />
    <pathelement location="${droolsPath}/knowledge-api.jar" />
    <pathelement location="${droolsPath}/drools-core.jar" />
    <pathelement location="${droolsPath}/drools-compiler.jar" />
    <pathelement location="${droolsPath}/antlr-runtime.jar" />
    <pathelement location="${droolsPath}/mvel2.jar" />
    <pathelement location="${droolsPath}/ecj.jar" />
    <pathelement location="${droolsPath}/slf4j-api.jar" />
  </path>

Code listing 4: The build.xml file – Drools classpath definition (part 2/4)

Note that the libraries in the code listing don't have versions. It has been removed to make this code listing more concise. For example, if you're using Version 5.5.0.Final of Drools, drools-ant.jar will be drools-ant-5.5.0.Final.jar.

The drools.classpath classpath references Drools artifacts that are required by validation rules (including their dependencies). You can add more Drools artifacts to this list depending on which features you're using (for example, if you use decision tables, add drools-decisiontables.jar and so on). Please note the use of the droolsPath variable to locate all Drools libraries.

The drools-ant.jar file contains the Drools Ant task. We'll now use the drools.classpath classpath to tell Ant about the Ant task.

  <taskdef name="compiler" classpathref="drools.classpath"
    classname="org.drools.contrib.DroolsCompilerAntTask" />

Code listing 5: The build.xml file – Drools compiler definition (part 3/4)

The taskdef element defines a compiler Ant task. It is implemented by class DroolsCompilerAntTask.

Now, we can use this Ant task to compile the validation rules:

  <path id="model.classpath">
    <pathelement location="${projectPath}lib/banking-model.jar" />
    <pathelement location="${projectPath}lib/joda-time.jar" />
  </path>

  <target name="compileArtifacts">
    <compiler srcdir="${projectPath}src/main/resources"
      tofile="${projectPath}target/validation.pkg"
      binformat="package" bintype="knowledge"
      classpathref="model.classpath">
      <include name="validation.drl" />      
    </compiler>
  </target>
</project>

Code listing 6: The build.xml file – target for building validation rules (part 4/4)

First, another classpath is defined called model.classpath. It contains all model libraries. In our case they are the banking-model.jar file and the joda-time.jar library. The first JAR file contains all classes used in the model. The second JAR file is a library that our model references.

Finally, the compileArtifacts target gathers all information together in order to compile the validation rules. The target's body consists of a compiler target. It defines:

  • srcdir: This points to the directory with our validation rules.
  • tofile: This specifies the destination file. In our case it is called validation.pkg.
  • binformat: This specifies that we want to build only a package, and if we didn't specify this, the whole knowledge base would be built.
  • bintype: This is here just for compatibility purposes. It should be always set to knowledge.
  • classpathref: This is a reference to our model classpath.

The body of the compiler element is a collection of files that should be compiled. In our case it is only one file called validation.drl. Other valid options are artifacts ending with .brl, .xml, .dsl, .dslr, .rf, .package, or .xls (note that there is no support for the .bpmn files). More files can be imported at once using wild cards (for example, all rule files with *.drl).

You can try this build file from a command line. Just navigate to the directory where it resides and type ant. Ant will execute the default target, which is in our case set to compileArtifacts. After a few seconds you should see a BUILD SUCCESSFUL message and the validation.pkg file should exist. This package can now be used to create a knowledge base.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.137.157.45