Hi all,

I'm a student doing my internship in an IT enterprise, the subject of this internship is to evaluate JBoss Rules, and see if it can replace ILOG Jrules in some of our client's projects
One important thing that can make Jboss Rules eligible is to have the possibility of synchronization between jboss\jbrms and eclipse\drool: this means to be able to access the Eclipse based rules project through the Jboss BRMS, and to be able to edit the rules and sync after the changes...
Is that possible with the current version of Drools?

Thank you very much for any help you can give me. (and sorry for my terrible english !!!)

Brahim EL ACHBOR

Hi all,

I'm a student doing my internship in an IT enterprise, the subject of this internship is to evaluate JBoss Rules, and see if it can replace ILOG Jrules in some of our client's projects
One important thing that can make Jboss Rules eligible is to have the possibility of synchronization between jboss\jbrms and eclipse\drool: this means to be able to access the Eclipse based rules project through the Jboss BRMS, and to be able to edit the rules and sync after the changes...
Is that possible with the current version of Drools?

Thank you very much for any help you can give me. (and sorry for my terrible english !!!)

Brahim EL ACHBOR _______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

The front-end of the BRMS destined for Drools 5 appears to use the GWT-EXT library, which in turn requires the Ext JS library. However, one of my colleagues has pointed out that as of April 21st 2008, the EXT JS library is now licensed under GPL (v3), whereas prior to this it was licensed under LGPL.

 

I don't know too much about licensing, but isn't this going to have an impact on the final Drools 5.0 licensing? From the little I know about licensing, if you use a GPL library (ext-core.js etc in the BRMS) then any derived code (e.g.. Drools) can only be distributed under GPL as well, so Drools couldn't be distributed under Apache 2 anymore?

 

Its a bit bonkers of EXT JS to suddenly change a license from LGPL to GPL and there is definitely a "heated" debate going on in the GWT-EXT and other forums. I hope it's appropriate to post this on the dev list, and apologies if not.

 

Regards

Shahad

 

_______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

I'm just doing a brain dump of how I think I'd like to see the 5.0 api

move, where we move from a rule oriented framework to a knowledge oriented framework for rules and processes. sounds interesting. how exactly do you see processes, integrated in the knowledgebase, other than just calling ordinary java classes in the then part of a rule? Will there be support for other AI-type algorithms?

Christine

A rough namespace and interface mapping could be as follows: org.drools KnowledgeBase <- RuleBase StatefulKnowledgeSession <- StatefulSession -extends both RuleSession and ProcessSession -in theory someone could have a rule or process specific impl although we will continue with the combined approach for now StatelessKnowledgeSession <- StatelessSession RuleSession -contains the rule specific api from WorkingMemory ProcessSession -contains the process specific api from WorkingMemory org.drools.events org.drools.knowledge.defintions KnowledgeDefinitionPackage <- Package -Possible just KnowledgePackage but I like reinforcing that these are definitions org.drools.knowledge.defintions.rules <- org.drools.rule org.drools.knowledge.defintions.processes org.drools.knowledge.defintions.models -will eventually contain our ontology stuff org.drools.knowledge.defintions.models.facttemplate <- org.drools.factemplates org.drools.knowledge.defintions.models.pojo -our current pojo model stuff should probably go here too org.drools.knowledge.engines.rules <- org.drools.reteoo (and common,

base, spi etc which will also be refactored)

org.drools.knowledge.engines.processes We will create a drools-api module. This will contain all public user

apis for all modules in the project, which will allow us to support service frameworks better, such as OSGi. This will also allow us to more easily differentiate from public stable apis and internal apis.

To get compability with 4.0.x we'll have a drools4-adapter jar, which

will keep all the 4.0 names and just wrap and delegate to the new impl. We won't be able to achieve 100% api comptability, but we should be able to for all the most common public apis.

Mark _______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

There is nothing planned for 5.0 beyond rules, processes and cep. But yes I'd like to see other things be included, if they can be integrated and unified in a meaningful way.

I was thinking of a blackboard. That's simple to implement yourself, but it would be convenient to have it in Drools.

Christine _______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev