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