[rules-dev] New module created: knowledge-internal-api

[Esteban Aliverti]

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?

Best Regards,

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Esteban Aliverti
- Developer @ http://www.plugtree.com
- Blog @ http://ilesteban.wordpress.com


On Tue, Dec 13, 2011 at 9:15 AM, Mark Proctor <mproctor at codehaus.org> 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<ge0ffrey.spam at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-dev
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20111213/ed1103af/attachment-0001.html