[rules-users] Drools5M3 Issues

[Mark Proctor]

keithnielsen wrote:
> Ok,
>
> I tried to upgrade from M2 to M3. Big Mistake
>
> I see that you have attempted to separate the interface from the
> implementation by moving most of
> the interfaces that are intended for public consumption from drools-core to
> a new jar file called drools-api. 
> Unfortunately there appears a few different problems with this
>
> 1) Unfortunately you have duplicated package names (drools.core) as well
> duplicated numerous classes across the two jar files
> (WorkingMemoryEntryPoint and FactHandle to name a few) 
>   
Some Classes remain, now in a deprecated manner, in drools-core. 
Duplicate names are always in a different pacage to avoid clashing. It 
is recommended that you use the org.drools.runtime.rule.FactHandle, 
which is now considered the stable api. Over time core/compiler will 
implement drools-api instead of bridging and adapting it, and drools4.0 
classes/interfaces will go to an optional jar. But we didn't want to 
change too much at the beginning, so as to retain backwards compatability.
> 2) StatefulSession interface has not been moved to drools-api and only exist
> in drools-core
>   
That is correct. You should now use StatefulKnowledgeSession. You can 
continue to use StatefulSession, we have tried to not break any 
Drools4.0 code, for a level of backwards
compatability, but any interfaces/classes that you use in Drools4.0, 
should be considered deprecated. As mentioned above, we will move these 
4.0 specific classes to an optional jar over time.
> This makes this build unusable in Eclipse 3.4 as is. Also I am using Eclipse
> as a runtime platform and this makes it impossible to simply expose the api
> classes as intended, because when you you embed the rules engine as a plugin
> you have to expose those packages containing the api you wish to expose, in
> drools case that would be drools-api, unfortunately StatefulSession is still
> in drools-core for example forcing me to export both drools-core and
> drools-api which defeats the purpose of having drools-api since I have to
> expose implementation classes from drools-core which also now exposes
> duplicate classes, such as FactHandle and WorkingMemoryEntryPoint
>   
If you are writting new software, use the new drools-api interfaces, not 
the deprecated ones and you won't have this issue.

Mark