[rules-dev] Re: [rules-users] Drools5M3 Issues

[Michael Neale]

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