Upgrade to protobuf 2.5 (and how to work with Protobuf)
by Edson Tirelli
All,
Today protobuf used by Drools/jBPM was upgrade to version 2.5.0. If you
only use the marshalling code, you don't need to do anything. Maven should
automatically download the new version and use it.
If you do protobuf development and need to re-generate the protobuf
classes from time to time, here is a reminder of how to configure your
environment. Please note that the configuration of the plugin (specially
for the jBPM module) is extremely important, or you will start to have all
kinds of errors and will not know why.
1. Download and install protobuf compiler from: http://code.google.com/p/
protobuf/downloads/list
2. Install protobuf-dt eclipse plugin as detailed here:
http://code.google.com/p/protobuf-dt/
3. Configure the destination directory to generate the java files as
detailed in step 2 here:
http://code.google.com/p/protobuf-dt/wiki/IntegrationWithProtoc
Set the "Java Output Directory" to: src/main/java
4. VERY IMPORTANT FOR JBPM: jBPM Flow project has a .proto file that
extends the data types defined in the .proto file in Drools Core, so you
need to configure the protobuf import path as detailed here:
http://code.google.com/p/protobuf-dt/wiki/ImportPaths
Add the following import paths to the jbpm-flow project:
${your drools-core project in eclipse}/src/main/resources
${your_drools_flow_project}/src/main/resources
After doing that, when you edit and save the .proto files, eclipse will
automatically compile and regenerate the java source code for them.--
Edson
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
12 years, 7 months
KIE api verbosity
by Geoffrey De Smet
I've upgraded OptaPlanner to use the KIE api and I have some feedback :)
What I want to do:
*Given of list of DRL's on the classpath, build a KieSession.*
Here's how I did it with the new KIE api:
public KieBase newKieBase(List<String> scoreDrlList) {
KieServices kieServices = KieServices.Factory.get();
KieResources kieResources = kieServices.getResources();
KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
for (String scoreDrl : scoreDrlList) {
InputStream scoreDrlIn =
getClass().getResourceAsStream(scoreDrl);
// TODO newClassPathResource() instead, but that breaks
(mfusco is looking at it)
String path =
"src/main/resources/optaplanner-kie-namespace/" + scoreDrl;
kieFileSystem.write(path,
kieResources.newInputStreamResource(scoreDrlIn, "UTF-8"));
}
KieBuilder kieBuilder = kieServices.newKieBuilder(kieFileSystem);
kieBuilder.buildAll();
Results results = kieBuilder.getResults();
if (results.hasMessages(Message.Level.ERROR)) {
throw new IllegalStateException("There are errors in
the scoreDrl's:\n"
+ results.toString());
} else if (results.hasMessages(Message.Level.WARNING)) {
logger.warn("There are warning in the scoreDrl's:\n"
+ results.toString());
}
KieContainer kieContainer =
kieServices.newKieContainer(kieBuilder.getKieModule().getReleaseId());
KieBase kieBase = kieContainer.getKieBase();
return kieBase;
}
public KieSession newKieSession() {
...
KieSession kieSession = kieBase.newKieSession();
return kieSession;
}
*Feedback* (note: these are suggestions, not demands):
1) To do this, I needed to get acquainted with 9 new concepts:
KieServices, KieResources, KieFileSystem, KieBuilder, Results,
KieModule, KieContainer, KieBase, KieSession.
I only care about 2 of those:
- KieSession
- KieBase (= the factory to build a new KieSession, which I do regularly).
The other 7 concepts probably represent wonderful advanced features
which I might want to use later on,
so they should exist,
But in a simple use case like this, I should not have to see them or
deal with them.
2) The kie filesystem features leaks into the simple api, even if I
don't care about the KieFileSystem at all.
- I should not explicitly need to create a KieFileSystem:
KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
- Adding certain Resource types fails if you don't specify the
fileSystem's path. This fails for example:
kieFileSystem.write(kieResources.newInputStreamResource(...));
- For the default KieBase to work, the path needs to start with a
magical prefix
String path = "src/main/resources/.../" + ...;
3) To create a KieBase from that kieFileSystem, I need to explicitly do
5+ calls, in the right order:
- call kieServices.newKieBuilder(...)
- call kieBuilder.buildAll()
- call kieBuilder.getKieModule()
- call kieServices.newKieContainer(...)
- call kieContainer.getKieBase()
Some of these have non-obvious parameters.
I'd rather just call:
kieFileSystem.buildKieBase()
4) I don't like having to write the boilerplate code to check if the are
errors:
if (results.hasMessages(Message.Level.ERROR)) {...}
If there are errors, then kieFileSystem.buildKieBase() should just throw
a DroolsRuntimeException.
*Solution* proposal:
A) Write a facade class that presumes there is only 1 module and the
user doesn't need (or want to) to access any of those 7 other concepts.
public KieBase newKieBase(List<String> scoreDrlList) {
KieBaseFactory kieBaseFactory = kieServices.newKieBaseFactory();
for (String scoreDrl : scoreDrlList) {
kieBaseFactory.addInputStreamResource(scoreDrl, "UTF-8");
}
return kieBaseFactory.buildKieBase; // throws exception upon
compilation error
}
Mario's KieHelper is similar, but slightly different.
wkr,
Geoffrey
12 years, 7 months
Kie: pluggable builders
by Michael Anstis
I was thinking over the weekend.
Guvnor has many different file types it uses to store rule definitions.
Currently Guvnor builds DRL before passing this to KieBuilder via
KieStorage (erm, will do this).
Any thoughts on moving the conversion to DRL from Guvnor to pluggable
builders within Kie that accept defined file-types (you have DRL and XLS at
the moment).
This further makes Guvnor just the "rule management" component having
knowledge base building (from any resource type) within Expert.
Guvnor would obviously provide all the pluggable builders it needs for 6.0.
Just a thought...
sent on the move
12 years, 7 months
problem with droolsjbpm git repo ?
by Cristiano Gavião
Hello,
I would like to discuss a problem that I'm facing with the git
repositories from droolsjbpm when using it with eclipse Jgit/Egit.
The problem is that after import the projects into eclipse IDE and
'shared them with git', all files seems to be modified.
I could find the same type of problem here:
http://stackoverflow.com/questions/8227233/the-is-nothing-changed-but-ecl...
The worst is if I do a "format" in the code file, seems as the entire
file have changed. :(
As I use MacOS I've setup my system *core.autocrlf* with 'input' as
stated here: https://help.github.com/articles/dealing-with-line-endings
I've been using egit for a long time and I only face this kind of
problem with droolsjbpm repos.
What kind of SO and IDE do you guys use at RedHat ?
Any of you had this kind of problem? any tip how to deal with ?
thanks and regards,
Cristiano
12 years, 7 months
When a rule equals a rule
by Wolfgang Laun
There was this thread about comparing compiled and serialized
packages. Somewhat interested, I decided to run a few tests. (Now I
know that the IdentityHashMap used in there somewhere dooms all
efforts.)
It is possible to detect the addition or removal of rules by comparing
the rules contained in the KnowledgePackages, using
KnowledgePackage.getRules() and by keeping track of the rules
identified by names. Good.
Then I used org.drools.definition.rule.Rule's method equals(), but
this returns stubbornly true, even when rules actually differ. I
thought that this was due to org.drools.definition.rule.Rule's
implementation (in org.drools.definitions.rule.impl.RuleImpl) just
being a "shadow" object, hiding the hot stuff that's kept in an
org.drools.rule.Rule object.
But changing something that *is* exposed - namely the rule's metadata
- still didn't make equals() false.
So I looked at
org.drools.definitions.rule.impl.RuleImpl.equals(), and was quite
astonished to see that this one does call the equals() of the real
McCoy, i.e., org.drools.rule.Rule.equals(). Looking at this method
made it clear to me that this method isn't good for comparing rules
beyond the scope of a single knowledge base or knowledge builder: it
is firmly rooted in the assumption that rule name and the rule's
package name are "The Rule".
-W
12 years, 7 months
Drools Planner renames to OptaPlanner: Announcing www.optaplanner.org
by Geoffrey De Smet
We’re proud to announce the rename Drools Planner to OptaPlanner
starting with version 6.0.0.Beta1. We’re also happy to unveil its new
website: www.optaplanner.org <http://www.optaplanner.org>.
OptaPlanner optimizes business resource usage. Every organization faces
planning problems: provide products or services with a limited set of
constrainedresources (employees, assets, time and money). OptaPlanner
optimizes such planning to do more business with less resources. Typical
use cases include vehicle routing, employee rostering and equipment
scheduling.
OptaPlanner is a lightweight, embeddable planning engine written in
Java™. It helps normal Java™ programmers solve constraint satisfaction
problems efficiently. Under the hood, it combines optimization
heuristics and metaheuristics with very efficient score calculation.
OptaPlanner is open source software, released under the Apache Software
License <http://www.jboss.org/optaplanner/code/license.html>. It is 100%
pure Java™, runs on the JVM and is available in the Maven Central
Repository <http://www.jboss.org/optaplanner/download/download.html>too.
For more information, visit the new website:
http://www.optaplanner.org
Why change the name?
OptaPlanner is the new name for Drools Planner. OptaPlanner is now
standalone, but can still be optionally combined with the Drools rule
engine for a powerful declarative approach to planning optimization.
*
OptaPlanner has graduated from the Drools
<http://www.jboss.org/drools>project to become a top-level JBoss
Community <http://www.jboss.org/>project.
o
OptaPlanner is not a fork of Drools Planner. We simply renamed it.
o
OptaPlanner (the planning engine) joins its siblings Drools (the
rule engine) and jBPM (the workflow engine) in the KIE group.
*
Our commitment to Drools hasn't changed.
o
The efficient Drools rule engine is still the recommended way to
do score calculation.
o
Alternative score calculation options, such as pure Java
calculation (no Drools), also remain fully supported.
How will this affect your business?
From a business point of view, there's little or no change:
*
The mission remains unchanged:
o
We're still 100% committed to put business resource
optimizationin the hands of normal Java developers.
*
The license remains unchanged (Apache Software License 2.0). It's
still the same open source license.
*
The release lifecycle remains unchanged: OptaPlanner is still
released at the same time as Drools and jBPM.
*
Red Hat is considering support subscription offerings for
OptaPlanner as part of its BRMS
<http://www.redhat.com/products/jbossenterprisemiddleware/business-rules/>and
BPM platforms.
o
A Tech Previewof OptaPlanner is targeted for BRMS 6.0.
What has changed?
*
The website has changed tohttp://www.optaplanner.org
*
The distributions artifacts have changed name:
o
Jar names changes:
+
drools-planner-core-*.jar is now optaplanner-core-*.jar
+
drools-planner-benchmark-*.jar is now
optaplanner-benchmark-*.jar
o
Maven identification groupId's and artifactId's changes:
+
groupId org.drools.planner is now org.optaplanner
+
artifactId drools-planner-core is now optaplanner-core
+
artifactId drools-planner-benchmark is now optaplanner-benchmark
o
As usual, for more information see the Upgrade Recipe in the
download zip.
*
The API's namespace has changed. As usual, see the upgrade recipe
<https://github.com/droolsjbpm/optaplanner/blob/master/optaplanner-distrib...>on
how to deal with this efficiently.
o
Starting from 6.1.0.Final, OptaPlanner will have a 100%
backwards compatible API.
*
OptaPlanner gets its own IRC channels on Freenode
<http://freenode.net/>: #optaplanner and #optaplanner-dev
12 years, 7 months
Freeze status to fix split packages
by Geoffrey De Smet
Quick status update:
- Drools-compiler has been namespaced
- Drools-core has been *partially* namespaced
Still todo:
- drools-core (the rest)
- kie-internal
- kie-api
There are no compile errors currently.
Edson is working on getting the tests etc running again.
I 'll try to finish drools-core on Sunday (if possible).
*Feel free to push commits between now and Sunday morning, but make sure
they compile (including downstream).*
Next status update on Sunday evening.
We 'll probably delay splitting kie-api and kie-internal to a later date
next week.
12 years, 7 months
