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?

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

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 <http://www.plugtree.com> - Blog @ http://ilesteban.wordpress.com On Tue, Dec 13, 2011 at 9:15 AM, Mark Proctor <mproctor(a)codehaus.org <mailto:mproctor@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&lt;ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@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 <mailto:rules-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@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