[rules-dev] refactoring for a knowledge oriented product

[Mark Proctor]

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