[rules-dev] refactoring for a knowledge oriented product

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