No that won't help as it still is the same classname from the IDE
content assistance point of view.
No quick fix I can see, the only 3 options are to tweak the IDE to
ignore the "old" or internal ones, or use differnt classnames for the
new ones ;) - probably not practical.
Sent from my iPhone
On 29/11/2008, at 7:38, Mark Proctor <mproctor(a)codehaus.org> wrote:
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 Proctor wrote:
> keithnielsen wrote:
>> 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
>> 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.
> rules-users mailing list
rules-dev mailing list