JBoss.org Community Documentation

- Prev
- Next

## Chapter 2. Release Notes

## 2.1. New and Noteworthy in KIE Workbench 6.2.0

### 2.1.1. Project Editor permissions

The ability to configure role-based permissions for the Project Editor have been added.

Permissions can be configured using the `WEB-INF/classes/workbench-policy.properties` file.

The following permissions are supported:-

- Save button

  `feature.wb_project_authoring_save`

- Delete button

  `feature.wb_project_authoring_delete`

- Copy button

  `feature.wb_project_authoring_copy`

- Rename button

  `feature.wb_project_authoring_rename`

- Build & Deploy button

  `feature.wb_project_authoring_buildAndDeploy`

### 2.1.2. Unify validation style in Guided Decision Table Wizard.

All of our new screens use GWT-Bootstrap widgets and alert users to input errors in a consistent way.

One of the most noticable differences was the Guided Decision Table Wizard that alerted errors in a way inconsistent with our use of GWT-Bootstrap.

This Wizard has been updated to use the new look and feel.

Figure 2.1. New Guided Decision Table Wizard validation

### 2.1.3. Improved Wizards

During the re-work of the Guided Decision Table's Wizard to make it's validation consistent with other areas of the application we took the opportunity to move the Wizard Framework to GWT-Bootstrap too.

The resulting appearance is much more pleasing. We hope to migrate more legacy editors to GWT-Bootstrap as time and priorities permit.

Figure 2.2. New Wizard Framework

### 2.1.4. Consistent behaviour of XLS, Guided Decision Tables and Guided Templates

Consistency is a good thing for everybody. Users can expect different authoring metaphores to produce the same rule behaviour (and developers know when something is a bug!).

There were a few inconsistencies in the way XLS Decision Tables, Guidied Decision Tables and Guided Rule Templates generated the underlying rules for empty cells. These have been eliminated making their operation consistent.

- If all constraints have null values (empty cells) the Pattern is not created.

  Should you need the Pattern but no constraints; you will need to include the constraint `this != null`.

  This operation is consistent with how XLS and Guided Decision Tables have always worked.

- You can define a constraint on a String field for an empty String or white-space by delimiting it with double-quotation marks. The enclosing quotation-marks are removed from the value when generating the rules.

  The use of quotation marks for other String values is not required and they can be omitted. Their use is however essential to differentiate a constraint for an empty String from an empty cell - in which case the constraint is omitted.

### 2.1.5. Improved Metadata Tab

The Metadata tab provided in previous versions was redesigned to provide a better asset versioning information browsing and recovery. Now every workbench editor will provide an "Overview tab" that will enable the user to manage the following information.

Figure 2.3. Improved Metadata Tab

- Versions history

  The versions history shows a tabular view of the asset versions and provides a "Select" button that will enable the user to load a previously created version.

  Figure 2.4. Versions history

- Metadata

  The metadata section gets access to additional file attributes.

  Figure 2.5. Metadata section

- Comments area

  The redesigned comments area enables much clearer discussions on a file.

- Version selection dropdown

  The "Version selector dropdown" located at the menu bar provides the ability to load and restore previous versions from the "Editor tab", without having to open the "Overview tab" to load the "Version history".

  Figure 2.6. Version selection dropdown

### 2.1.6. Improved Java Editor

The Java editor was unified to the standard workbench editors functioning. It means that and now every Java file is edited on his own editor window.

Figure 2.7. Improved Java Editor

- "New -> Java" file option was added to create the java classes.

- Overview tab was added for every Java file to manage the file metadata and have access to the file versions history.

- Editable "Source Tab" tab was added. Now the Java code can be modified using the workbench.

- "Editor" - "Source Tab" round trip is provided. This will let the user to do manual changes on the generated Java code and go back to the editor tab to continue working.

- Class usages detection. Whenever a Java file is about to be deleted or renamed, the project will be scanned for the class usages. If usages are found (e.g. in drl files, decision tables, etc.) the user will receive an alert. This will prevent the user from breaking the project build.

  Figure 2.8. Usages detection

### 2.1.7. Execution Server Management UI

A new perspective called Management has been added under Servers top level menu. This perspective provides users the ability to manage multiple execution servers with multiple containers. Available features includes connect to already deployed execution servers; create new, start, stop, delete or upgrade containers.

Figure 2.9. Management perspective

## Note

Current version of Execution Server just supports rule based execution.

### 2.1.8. Social Activities

A brand new feature called Social Activities has been added under a new top level menu item group called Activity.

This new feature is divided in two different perspectives: Timeline Perspective and People Perspective.

The Timeline Perspective shows on left side the recent assets created or edited by the logged user. In the main window there is the "Latest Changes" screen, showing all the recent updated assets and an option to filter the recent updates by repository.

Figure 2.10. Timeline Perspective

The People Perspective is the home page of an user. Showing his infos (including a gravatar picture from user e-mail), user connections (people that user follow) and user recent activities. There is also a way to edit an user info. The search suggestion can be used to navigate to a user profile, follow him and see his updates on your timeline.

Figure 2.11. People Perspective

Figure 2.12. Edit User Info

### 2.1.9. Contributors Dashboard

A brand new perspective called Contributors has been added under a new top level menu item group called Activity. The perspective itself is a dashboard which shows several indicators about the contributions made to the managed organizations / repositories within the workbench. Every time a organization/repository is added/removed from the workbench the dashboard itself is updated accordingly.

This new perspective allows for the monitoring of the underlying activity on the managed repositories.

Figure 2.13. Contributors perspective

### 2.1.10. Package selector

The location of new assets whilst authoring was driven by the context of the Project Explorer.

This has been replaced with a Package Selector in the New Resource Popup.

The location defaults to the Project Explorer context but different packages can now be more easily chosen.

Figure 2.14. Package selector

### 2.1.11. Improved visual consistency

All Popups have been refactored to use GWT-Bootstrap widgets.

Whilst a simple change it brings greater visual consistency to the application as a whole.

Figure 2.15. Example Guided Decision Table Editor popup

Figure 2.16. Example Guided Rule Editor popup

## 2.2. New and Noteworthy in Integration 6.2.0

### 2.2.1. Kie Server

A new Kie Execution Server was created with the goal of supporting the deployment of kjars and the automatic creation of REST endpoints for remote rules execution. This initial implementation supports provisioning and execution of kjars via REST without any glue code.

A user interface was also integrated into the workbench for remote provisioning. See the workbench's New&Noteworthy for details.

    @Path("/server")

    public interface KieServer {

        @GET

        @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        public Response getInfo();

        @POST

        @Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        public Response execute( CommandScript command );

        @GET

        @Path("containers")

        @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        public Response listContainers();

        @GET

        @Path("containers/{id}")

        @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        public Response getContainerInfo( @PathParam("id") String id );

        @PUT

        @Path("containers/{id}")

        @Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        public Response createContainer( @PathParam("id") String id, KieContainerResource container );

        @DELETE

        @Path("containers/{id}")

        @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        public Response disposeContainer( @PathParam("id") String id );

        @POST

        @Path("containers/{id}")

        @Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        public Response execute( @PathParam("id") String id, String cmdPayload );

        @GET

        @Path("containers/{id}/release-id")

        @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        public Response getReleaseId( @PathParam("id") String id);

        @POST

        @Path("containers/{id}/release-id")

        @Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        public Response updateReleaseId( @PathParam("id") String id, ReleaseId releaseId );

        @GET

        @Path("containers/{id}/scanner")

        @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        public Response getScannerInfo( @PathParam("id") String id );

        @POST

        @Path("containers/{id}/scanner")

        @Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})

        public Response updateScanner( @PathParam("id") String id, KieScannerResource resource );

    }

Figure 2.17. Kie Server interface

## 2.3. What is New and Noteworthy in Drools 6.1.0

### 2.3.1. JMX support for KieScanner

Added support for JMX monitoring and management on KieScanner and KieContainer. To enable, set the property:

KieScannerMBean will register under the name:

It exposes the following properties:

- Scanner Release Id: the release ID the scanner was configured with. May include maven range versions and special keywords like LATEST, SNAPSHOT, etc.

- Current Release Id: the actual release ID the artifact resolved to.

- Status: STARTING, SCANNING, UPDATING, RUNNING, STOPPED, SHUTDOWN

It also exposes the following operations:

- scanNow(): forces an immediate scan of the maven repository looking for artifact updates

- start(): starts polling the maven repository for artifact updates based on the polling interval parameter

- stop(): stops automatically polling the maven repository

## 2.4. New and Noteworthy in KIE Workbench 6.1.0

### 2.4.1. Data Modeler - round trip and source code preservation

Full round trip between Data modeler and Java source code is now supported. No matter where the Java code was generated (e.g. Eclipse, Data modeller), data modeler will only update the necessary code blocks to maintain the model updated.

### 2.4.2. Data Modeler - improved annotations

New annotations @TypeSafe, @ClassReactive, @PropertyReactive, @Timestamp, @Duration and @Expires were added in order enrich current Drools annotations manged by the data modeler.

### 2.4.3. Standardization of the display of tabular data

We have standardized the display of tabular data with a new table widget.

The new table supports the following features:

- Selection of visible columns

- Resizable columns

- Moveable columns

Figure 2.18. New table

The table is used in the following scenarios:

- Inbox (Incoming changes)

- Inbox (Recently edited)

- Inbox (Recently opened)

- Project Problems summary

- Artifact Repository browser

- Project Editor Dependency grid

- Project Editor KSession grid

- Project Editor Work Item Handlers Configuration grid

- Project Editor Listeners Configuration grid

- Search Results grid

### 2.4.4. Generation of `modify(x) {...}` blocks

The Guided Rule Editor, Guided Template Editor and Guided Decision Table Editor have been changed to generate `modify(x){...}`

Historically these editors supported the older `update(x)` syntax and hence rules created within the Workbench would not respond correctly to `@PropertyReactive` and associated annotations within a model. This has now been rectified with the use of `modify(x){...}` blocks.

## 2.5. New and Noteworthy in KIE API 6.0.0

### 2.5.1. New KIE name

KIE is the new umbrella name used to group together our related projects; as the family continues to grow. KIE is also used for the generic parts of unified API; such as building, deploying and loading. This replaces the droolsjbpm and knowledge keywords that would have been used before.

Figure 2.19. KIE Anatomy

### 2.5.2. Maven aligned projects and modules and Maven Deployment

One of the biggest complaints during the 5.x series was the lack of defined methodology for deployment. The mechanism used by Drools and jBPM was very flexible, but it was too flexible. A big focus for 6.0 was streamlining the build, deploy and loading (utilization) aspects of the system. Building and deploying activities are now aligned with Maven and Maven repositories. The utilization for loading rules and processess is now convention and configuration oriented, instead of programmatic, with sane defaults to minimise the configuration.

Projects can be built with Maven and installed to the local M2_REPO or remote Maven repositories. Maven is then used to declare and build the classpath of dependencies, for KIE to access.

### 2.5.3. Configuration and convention based projects

The 'kmodule.xml' provides declarative configuration for KIE projects. Conventions and defaults are used to reduce the amount of configuration needed.

Example 2.1. Declare KieBases and KieSessions

    <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">

      <kbase name="kbase1" packages="org.mypackages>

        <ksession name="ksession1"/>

      </kbase>

    </kmodule>

Example 2.2. Utilize the KieSession

    KieServices ks = KieServices.Factory.get();

    KieContainer kContainer = ks.getKieClasspathContainer();

    KieSession kSession = kContainer.newKieSession("ksession1");

    kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));

    kSession.fireAllRules();

### 2.5.4. KieBase Inclusion

It is possible to include all the KIE artifacts belonging to a KieBase into a second KieBase. This means that the second KieBase, in addition to all the rules, function and processes directly defined into it, will also contain the ones created in the included KieBase. This inclusion can be done declaratively in the kmodule.xml file

Example 2.3. Including a KieBase into another declaratively

    <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">

      <kbase name="kbase2" includes="kbase1">

        <ksession name="ksession2"/>

      </kbase>

    </kmodule>

or programmatically using the `KieModuleModel`.

Example 2.4. Including a KieBase into another programmatically

    KieModuleModel kmodule = KieServices.Factory.get().newKieModuleModel();

    KieBaseModel kieBaseModel1 = kmodule.newKieBaseModel("KBase2").addInclude("KBase1");

### 2.5.5. KieModules, KieContainer and KIE-CI

Any Maven produced JAR with a 'kmodule.xml' in it is considered a KieModule. This can be loaded from the classpath or dynamically at runtime from a Resource location. If the kie-ci dependency is on the classpath it embeds Maven and all resolving is done automatically using Maven and can access local or remote repositories. Settings.xml is obeyed for Maven configuration.

The KieContainer provides a runtime to utilize the KieModule, versioning is built in throughout, via Maven. Kie-ci will create a classpath dynamically from all the Maven declared dependencies for the artifact being loaded. Maven LATEST, SNAPSHOT, RELEASE and version ranges are supported.

Example 2.5. Utilize and Run - Java

    KieServices ks = KieServices.Factory.get();

    KieContainer kContainer = ks.newKieContainer(

            ks.newReleaseId("org.mygroup", "myartefact", "1.0") );

    KieSession kSession = kContainer.newKieSession("ksession1");

    kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));

    kSession.fireAllRules();

KieContainers can be dynamically updated to a specific version, and resolved through Maven if KIE-CI is on the classpath. For stateful KieSessions the existing sessions are incrementally updated.

Example 2.6. Dynamically Update - Java

    KieContainer kContainer.updateToVersion(

                    ks.newReleaseId("org.mygroup", "myartefact", "1.1") );

### 2.5.6. KieScanner

The `KieScanner` is a Maven-oriented replacement of the KnowledgeAgent present in Drools 5. It continuously monitors your Maven repository to check if a new release of a Kie project has been installed and if so, deploys it in the `KieContainer` wrapping that project. The use of the `KieScanner` requires kie-ci.jar to be on the classpath.

A `KieScanner` can be registered on a `KieContainer` as in the following example.

Example 2.7. Registering and starting a KieScanner on a KieContainer

    KieServices kieServices = KieServices.Factory.get();

    ReleaseId releaseId = kieServices.newReleaseId( "org.acme", "myartifact", "1.0-SNAPSHOT" );

    KieContainer kContainer = kieServices.newKieContainer( releaseId );

    KieScanner kScanner = kieServices.newKieScanner( kContainer );

    // Start the KieScanner polling the Maven repository every 10 seconds

    kScanner.start( 10000L );

In this example the `KieScanner` is configured to run with a fixed time interval, but it is also possible to run it on demand by invoking the `scanNow()` method on it. If the `KieScanner` finds, in the Maven repository, an updated version of the Kie project used by that `KieContainer` it automatically downloads the new version and triggers an incremental build of the new project. From this moment all the new `KieBase`s and `KieSession`s created from that `KieContainer` will use the new project version.

### 2.5.7. Hierarchical ClassLoader

The CompositeClassLoader is no longer used; as it was a constant source of performance problems and bugs. Traditional hierarchical classloaders are now used. The root classloader is at the KieContext level, with one child ClassLoader per namespace. This makes it cleaner to add and remove rules, but there can now be no referencing between namespaces in DRL files; i.e. functions can only be used by the namespaces that declared them. The recommendation is to use static Java methods in your project, which is visible to all namespaces; but those cannot (like other classes on the root KieContainer ClassLoader) be dynamically updated.

### 2.5.8. Legacy API Adapter

The 5.x API for building and running with Drools and jBPM is still available through Maven dependency "knowledge-api-legacy5-adapter". Because the nature of deployment has significantly changed in 6.0, it was not possible to provide an adapter bridge for the KnowledgeAgent. If any other methods are missing or problematic, please open a JIRA, and we'll fix for 6.1

### 2.5.9. KIE Documentation

While a lot of new documentation has been added for working with the new KIE API, the entire documentation has not yet been brought up to date. For this reason there will be continued references to old terminologies. Apologies in advance, and thank you for your patience. We hope those in the community will work with us to get the documentation updated throughout, for 6.1

## 2.6. What is New and Noteworthy in Drools 6.0.0

### 2.6.1. PHREAK - Lazy rule matching algorithm

The main work done for Drools in 6.0 involves the new PREAK algorithm. This is a lazy algorithm that should enable Drools to handle a larger number of rules and facts. AngendaGroups can now help improvement performance, as rules are not evaluated until it attempts to fire them.

Sequential mode continues to be supported for PHREAK but now 'modify' is allowed. While there is no 'inference' with sequential configuration, as rules are lazily evaluated, any rule not yet evaluated will see the more recent data as a result of 'modify'. This is more inline with how people intuitively think sequential works.

The conflict resolution order has been tweaked for PHREAK, and now is ordered by salience and then rule order; based on the rule position in the file.. Prior to Drools 6.0.0, after salience, it was considered arbitrary. When KieModules and updateToVersion are used for dynamic deployment, the rule order in the file is preserved via the diff processing.

### 2.6.2. Automatically firing timed rule in passive mode

When the rule engine runs in passive mode (i.e.: using fireAllRules) by default it doesn't fire consequences of timed rules unless fireAllRules isn't invoked again. Now it is possible to change this default behavior by configuring the KieSession with a `TimedRuleExectionOption` as shown in the following example.

Example 2.8. Configuring a KieSession to automatically execute timed rules

    KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration();

    ksconf.setOption( TimedRuleExectionOption.YES );

    KSession ksession = kbase.newKieSession(ksconf, null);

It is also possible to have a finer grained control on the timed rules that have to be automatically executed. To do this it is necessary to set a `FILTERED` `TimedRuleExectionOption` that allows to define a callback to filter those rules, as done in the next example.

Example 2.9. Configuring a filter to choose which timed rules should be automatically executed

    KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration();

    conf.setOption( new TimedRuleExectionOption.FILTERED(new TimedRuleExecutionFilter() {

        public boolean accept(Rule[] rules) {

            return rules[0].getName().equals("MyRule");

        }

    }) );

### 2.6.3. Expression Timers

It is now possible to define both the delay and interval of an interval timer as an expression instead of a fixed value. To do that it is necessary to declare the timer as an expression one (indicated by "expr:") as in the following example:

Example 2.10. An Expression Timer Example

    declare Bean

        delay   : String = "30s"

        period  : long = 60000

    end

    rule "Expression timer"

        timer( expr: $d, $p )

    when

        Bean( $d : delay, $p : period )

    then

    end

The expressions, $d and $p in this case, can use any variable defined in the pattern matching part of the rule and can be any String that can be parsed in a time duration or any numeric value that will be internally converted in a long representing a duration expressed in milliseconds.

Both interval and expression timers can have 3 optional parameters named "start", "end" and "repeat-limit". When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:

Example 2.11. An Interval Timer with a start and an end

    timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)

The value for start and end parameters can be a Date, a String representing a Date or a long, or more in general any Number, that will be transformed in a Java Date applying the following conversion:

    new Date( ((Number) n).longValue() )

Conversely the repeat-limit can be only an integer and it defines the maximum number of repetitions allowed by the timer. If both the end and the repeat-limit parameters are set the timer will stop when the first of the two will be matched.

The using of the start parameter implies the definition of a phase for the timer, where the beginning of the phase is given by the start itself plus the eventual delay. In other words in this case the timed rule will then be scheduled at times:

    start + delay + n*period

for up to repeat-limit times and no later than the end timestamp (whichever first). For instance the rule having the following interval timer

    timer ( int: 30s 1m; start="3-JAN-2010" )

will be scheduled at the 30th second of every minute after the midnight of the 3-JAN-2010. This also means that if for example you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.

### 2.6.4. RuleFowGroup and AgendaGroups are merged

These two groups have been merged and now RuleFlowGroup's behave the same as AgendaGroups. The get methods have been left, for deprecation reasons, but both return the same underlying data. When jBPM activates a group it now just calls setFocus. RuleFlowGroups and AgendaGroups when used together was a continued source of errors. It also aligns the codebase, towards PHREAK and the multi-core explotation that is planned in the future.

## 2.7. New and Noteworthy in KIE Workbench 6.0.0

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 workbench. 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 only 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.

Figure 2.20. Workbench

The Guvnor brand leaked too much from its intended role; such as the authoring metaphors, 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, BPMN2 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.

Figure 2.21. Module Structure

## Important

KIE Drools Workbench and KIE Workbench share a common set of components for generic workbench functionality such as Project navigation, Project definitions, 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.

## 2.8. New and Noteworthy in Integration 6.0.0

### 2.8.1. CDI

CDI is now tightly integrated into the KIE API. It can be used to inject versioned KieSession and KieBases.

    @Inject

    @KSession("kbase1")

    @KReleaseId( groupId = "jar1", rtifactId = "art1", version = "1.0")

    private KieBase kbase1v10;

    @Inject

    @KBase("kbase1")

    @KReleaseId( groupId = "jar1", rtifactId = "art1", version = "1.1")

    private KieBase kbase1v10;

Figure 2.22. Side by side version loading for 'jar1.KBase1' KieBase

    @Inject

    @KSession("ksession1")

    @KReleaseId( groupId = "jar1", rtifactId = "art1", version = "1.0")

    private KieSession ksessionv10;

    @Inject

    @KSession("ksession1")

    @KReleaseId( groupId = "jar1", rtifactId = "art1", version = "1.1")

    private KieSession ksessionv11;

Figure 2.23. Side by side version loading for 'jar1.KBase1' KieBase

### 2.8.2. Spring

Spring has been revamped and now integrated with KIE. Spring can replace the 'kmodule.xml' with a more powerful spring version. The aim is for consistency with kmodule.xml

### 2.8.3. Aries Blueprints

Aries blueprints is now also supported, and follows the work done for spring. The aim is for consistency with spring and kmodule.xml

### 2.8.4. OSGi Ready

All modules have been refactored to avoid package splitting, which was a problem in 5.x. Testing has been moved to PAX.

- PrevChapter 1. Introduction
- Top of page
- Front page
- NextChapter 3. Compatibility matrix