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