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