<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 13/12/2011 08:34, Esteban Aliverti wrote:
<blockquote
cite="mid:CAKsR9Q8Ybk0BcQYikQ7z751_3+FsdQmp-RKNp0WDtKtuRJ1_fg@mail.gmail.com"
type="cite">Brace yourself, more magical casts are coming :)
<div><br>
</div>
<div>I like the idea of have a well documented and stable api like
knowledge-api. I have some doubts though:</div>
<div>What is going to be the initial state of internal-api? </div>
<div>I see it has some utility classes now, but what is the idea?
To start from a copy of knowledge-api?</div>
<div>Is knowledge-api going to be independent of drools-core? <br>
</div>
</blockquote>
knowledge-api will be independant as it is now. knowledge-internal
will depend on -api and core on -internal.<br>
<br>
Mark<br>
<blockquote
cite="mid:CAKsR9Q8Ybk0BcQYikQ7z751_3+FsdQmp-RKNp0WDtKtuRJ1_fg@mail.gmail.com"
type="cite">
<div> </div>
<div>Best Regards,<br clear="all">
<br>
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX<br>
<br>
Esteban Aliverti<br>
- Developer @ <a moz-do-not-send="true"
href="http://www.plugtree.com" target="_blank">http://www.plugtree.com
</a><br>
- Blog @ <a moz-do-not-send="true"
href="http://ilesteban.wordpress.com" target="_blank">http://ilesteban.wordpress.com</a><br>
<br>
<br>
<div class="gmail_quote">On Tue, Dec 13, 2011 at 9:15 AM, Mark
Proctor <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 13/12/2011 01:34, Salaboy wrote:<br>
> 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?<br>
</div>
Abosolutely. Like knowledge-api the javadocs for this will
be published<br>
and available to the user, we can document the apis there in
the manual.<br>
However unlike knowledge-api everythig in internal-api is
considered<br>
subject to change, there is no guarantee we won't change
them. So it's a<br>
great "staging" ground for experimental apis that we want
users to play<br>
with for a while, but we don't want to lock down quite yet,
atleast not<br>
until we decide it's ready to go to knowledge-api.<br>
<span class="HOEnZb"><font color="#888888"><br>
Mark<br>
</font></span>
<div class="HOEnZb">
<div class="h5">><br>
> Cheers<br>
><br>
> - CTO @ <a moz-do-not-send="true"
href="http://www.plugtree.com" target="_blank">http://www.plugtree.com</a><br>
> - MyJourney @ <a moz-do-not-send="true"
href="http://salaboy.wordpress.com" target="_blank">http://salaboy.wordpress.com</a><br>
> - Co-Founder @ <a moz-do-not-send="true"
href="http://www.jbug.com.ar" target="_blank">http://www.jbug.com.ar</a><br>
> - Mauricio "Salaboy" Salatino -<br>
><br>
> On 12/12/2011, at 11:08, Geoffrey De Smet<<a
moz-do-not-send="true"
href="mailto:ge0ffrey.spam@gmail.com">ge0ffrey.spam@gmail.com</a>>
wrote:<br>
><br>
>> Hi guys,<br>
>><br>
>> At Mark's and Kris's request, I've created a
new module<br>
>> knowledge-internal-api in droolsjbpm-knowledge.<br>
>> This module will - in time - contain all the
internal API between<br>
>> drools, jBPM and guvnor.<br>
>><br>
>> Advantages:<br>
>><br>
>> 1) jBPM would no longer need to depend on
drools-core.<br>
>><br>
>> 2) It's clear that if you break backwards
compatibility of the API in<br>
>> that module, that drools version X won't work
with jbpm version X + 1<br>
>> (and vica versa).<br>
>> Or put differently, if you change something in
drools-core, you're safe<br>
>> (now you are not).<br>
>><br>
>> --<br>
>> With kind regards,<br>
>> Geoffrey De Smet<br>
>><br>
>><br>
>> _______________________________________________<br>
>> rules-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
> _______________________________________________<br>
> rules-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>