JBoss.orgCommunity Documentation

Chapter 25. Release Notes

25.1. New and Noteworthy in KIE API 6.0.0
25.1.1. New KIE name
25.1.2. Maven aligned projects and modules and Maven Deployment
25.1.3. Configuration and convention based projects
25.1.4. KieBase Inclusion
25.1.5. KieModules, KieContainer and KIE-CI
25.1.6. KieScanner
25.1.7. Hierarchical ClassLoader
25.1.8. Legacy API Adapter
25.1.9. KIE Documentation
25.2. New and Noteworthy in jBPM 6.0.0
25.2.1. KIE api
25.2.2. jBPM Core Engine
25.2.3. jBPM Designer
25.2.4. jBPM Data Modeler
25.2.5. Form Modeler
25.2.6. jBPM Console
25.2.7. BAM / Reporting
25.2.8. Workbench
25.2.9. Remote API
25.3. New and Noteworthy in KIE Workbench 6.0.0
25.4. New and Noteworthy in Integration 6.0.0
25.4.1. CDI
25.4.2. Spring
25.4.3. Aries Blueprints
25.4.4. OSGi Ready

The execution engine itself has (mostly) remained the same, although we've done various improvements in the following areas:

The task service has been refactored significantly as well, and the TaskService APIs have been moved to the public kie-api. Although the TaskService interfaces themselves haven't changed a lot, the internal implementation has been simplified. Auditing for the task-related operations (similar to the runtime engine auditing) has been added.

By default, a local task service will always be used by a ksession to perform various task-related operations (creating a task, being notified when a task is completed). Setting up a remote singleton task service and connecting multiple ksessions to this (using Mina or HornetQ) as was possible in jBPM5 is no longer possible, as it introduces more challenges that it brings advantages. Since the jBPM execution service now also provides a remote API for all task-related operations, we believe this setup is no longer necessary, and has been replaced by the use of a local task service in all use cases.

The workbench has had a big overhaul using a new base project called UberFire. UberFire is inspired by Eclipse and provides a clean, extensible and flexible framework for the workebench. The end result is not only a richer experience for our end users, but we can now develop more rapidly with a clean component based architecture. If you like he Workbench experience you can use UberFire today to build your own web based dashboard and console efforts.

As well as the move to a UberFire the other biggest change is the move from JCR to GIT; there is an utility project to help with migration. GIT is the most scalable and powerful source repository bar none. JGIT provides a solid OSS implementation for GIT. This addresses the continued performance problems with the various JCR implementations, which would slow down once the number of files and number of versions become too high. There has been a big "low tech" drive, to remove complexity. Everything is now stored as a file, including meta data. The database is ony there to provide fast indexing and search. So importing and exporting is all standard GIT and external sites, like GitHub, can be used to exchange repositories.

In 5.x developers would work with their own source repository and then push JCR, via the team provider. This team provider was not full featured and not available outside eclipse. GIT enables our repository to work any existing GIT tool or team provider. While not yet supported in the UI, this will be added over time, it is possible to connect to the repo and tag and branch and restore things.

The Guvnor brand leaked too much from it's intended role; such as the authoring metaphores, like Decision Tables, being considered Guvnor components instead of Drools components. This wasn't helped by the monolithic projects structure used in 5.x for Guvnor. In 6.0 Guvnor 's focus has been narrowed to encapsulates the set of UberFire plugins that provide the basis for building a web based IDE. Such as Maven integration for building and deploying, management of Maven repositories and activity notifications via inboxes. Drools and jBPM build workbench distributions using Uberfire as the base and including a set of plugins, such as Guvnor, along with their own plugins for things like decision tables, guided editors, bpm2 designer, human tasks.

The "Model Structure" diagram outlines the new project anatomy. The Drools workbench is called KIE-Drools-WB. KIE-WB is the uber workbench that combines all the Guvnor, Drools and jBPM plugins. The jBPM-WB is ghosted out, as it doesn't actually exist, being made redundant by KIE-WB.


KIE Drools Workbench and KIE Workbench share a common set of components for generic workbench functionality such as Project navigation, Project defintions, Maven based Projects, Maven Artifact Repository. These common features are described in more detail throughout this documentation.

The two primary distributions consist of:

  • KIE Drools Workbench

    • Drools Editors, for rules and supporting assets.

    • jBPM Designer, for Rule Flow and supporting assets.

  • KIE Workbench

    • Drools Editors, for rules and supporting assets.

    • jBPM Designer, for BPMN2 and supporting assets.

    • jBPM Console, runtime and Human Task support.

    • jBPM Form Builder.

    • BAM.

Workbench highlights:

  • New flexible Workbench environment, with perspectives and panels.

  • New packaging and build system following KIE API.

    • Maven based projects.

    • Maven Artifact Repository replaces Global Area, with full dependency support.

  • New Data Modeller replaces the declarative Fact Model Editor; bringing authoring of Java classes to the authoring environment. Java classes are packaged into the project and can be used within rules, processes etc and externally in your own applications.

  • Virtual File System replaces JCR with a default GIT based implementation.

    • Default GIT based implementation supports remote operations.

    • External modifications appear within the Workbench.

  • Incremental Build system showing, near real-time validation results of your project and assets.

The editors themselves are largely unchanged; however of note imports have moved from the package definition to individual editors so you need only import types used for an asset and not the package as a whole.