For now anything outside of drools-api is considered legacy, there are
simply too many classes to mark them all individually. We will try and
migrate all the old public apis to a separate optional jar, but it was
too much work to do for 5.0, where backwards compatability was a
priority. So at the moment drools-api wraps the legacy apis, eventually
drools-api will become the native impl and the legacy apis will wrap
drools-api.
Mark
Zoltan Farkas wrote:
Drools 5.0 comes with a new API.
I also suspect that the new api is located in a new package drools-api.
Ideally new software written will start using the new API.
Ideally it would be nice to separate the old api in a separate package
called something like drools-api-legacy, and I am sure that is the goal.
Would it make sense to add @deprecated to the old api? It would make
thing a little bit clearer for the devs who write code against the api.
regards
--zoly
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
