On 13/12/2011 08:34, Esteban Aliverti wrote:
Brace yourself, more magical casts are coming :)
I like the idea of have a well documented and stable api like
knowledge-api. I have some doubts though:
What is going to be the initial state of internal-api?
I see it has some utility classes now, but what is the idea? To start
from a copy of knowledge-api?
Is knowledge-api going to be independent of drools-core?
knowledge-api will be independant as it is now. knowledge-internal will
depend on -api and core on -internal.
Mark
Best Regards,
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Esteban Aliverti
- Developer @ http://www.plugtree.com <http://www.plugtree.com>
- Blog @ http://ilesteban.wordpress.com
On Tue, Dec 13, 2011 at 9:15 AM, Mark Proctor <[email protected]
<mailto:[email protected]>> wrote:
On 13/12/2011 01:34, Salaboy wrote:
> Cool, I imagine that this project will be used to define a new
API for all the modules right? Is this the project that we should
use for some of the experimental APIs? For a while I was pushing
some changes in the human tasks module interface, should I include
those APIs here?
Abosolutely. Like knowledge-api the javadocs for this will be
published
and available to the user, we can document the apis there in the
manual.
However unlike knowledge-api everythig in internal-api is considered
subject to change, there is no guarantee we won't change them. So
it's a
great "staging" ground for experimental apis that we want users to
play
with for a while, but we don't want to lock down quite yet,
atleast not
until we decide it's ready to go to knowledge-api.
Mark
>
> Cheers
>
> - CTO @ http://www.plugtree.com
> - MyJourney @ http://salaboy.wordpress.com
> - Co-Founder @ http://www.jbug.com.ar
> - Mauricio "Salaboy" Salatino -
>
> On 12/12/2011, at 11:08, Geoffrey De
Smet<[email protected] <mailto:[email protected]>> wrote:
>
>> Hi guys,
>>
>> At Mark's and Kris's request, I've created a new module
>> knowledge-internal-api in droolsjbpm-knowledge.
>> This module will - in time - contain all the internal API between
>> drools, jBPM and guvnor.
>>
>> Advantages:
>>
>> 1) jBPM would no longer need to depend on drools-core.
>>
>> 2) It's clear that if you break backwards compatibility of the
API in
>> that module, that drools version X won't work with jbpm version
X + 1
>> (and vica versa).
>> Or put differently, if you change something in drools-core,
you're safe
>> (now you are not).
>>
>> --
>> With kind regards,
>> Geoffrey De Smet
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
> _______________________________________________
> rules-dev mailing list
> [email protected] <mailto:[email protected]>
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
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
