Re: [rules-users] Drools5M3 Issues

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users