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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
