[rules-users] Drools5M3 Issues

[Mark Proctor]

one option is to put drools api under a totaly new namespace - 
org.drools5 instead of org.drools. But I'm not keen to do this, although 
I know hibernate did it moving to hibernate 3. I'm trying to get a CR 
out in a week or so, so what ever we decide, we are rapidly running out 
of time.

Mark
Mark Proctor wrote:
> 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
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>