<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
The "expose them in core first, later in api" is a good thing. +1
there.<br>
<br>
I was talking about a different aspect:<br>
once we move it to api, sooner or later, the AbstractResource trick
could prevent binary backwards incompatibility on the api module if
users have a custom Resource implementation.<br>
<br>
For example, this could heighten the change that jbpm 5.2 (which
would requires drools 5.4) would work with drools 5.5 too (if the
later adds a method on the Resource interface and jbpm implements
it).<br>
<br>
Op 12-09-11 10:18, Esteban Aliverti schreef:
<blockquote
cite="mid:CAKsR9Q-nusieURv7VT4c3HLdxJ1R7Cu2K7hhC0jgian1R9V5Kw@mail.gmail.com"
type="cite">Ok, I will move these attributes to drools-core
(InternalResource). Later, we can think about move them to
drools-api.
<div>Geoffrey, I like your idea, but I think that is not the
"drools way" :). What Mark wants is to always add new stuff in
core and later, when it is stable enough, publish it through
drool-api. I agree with this, but when the improvements are only
useful for api users (name and description are not used in
drools-core in any way) I find this a little bit cumbersome. The
feature is never going to be used if it is no exposed. Users
must always cast Resource to InternalResource if they want to
use this (And I see a lot of these casts even inside
drools-core). </div>
<div>But, as a general solution, I'm not against the
implementation of new features in core first and the exposure on
api later.</div>
<div><br>
</div>
<div>Best Regards,</div>
<div><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 Mon, Sep 12, 2011 at 9:04 AM,
Geoffrey De Smet <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ge0ffrey.spam@gmail.com">ge0ffrey.spam@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff"> We could use
Abstract* class trick (the Collections api does it and I
use it a lot in Planner):<br>
<br>
drools-api has:<br>
interface Resource<br>
abstract class AbstractResource implement Resource<br>
And the javadoc on interface Resource clearly states that
they should extend AbstractResource when implementing a
custom Resource. Same for the reference manual.<br>
(Similar to interface List and class AbstractList)<br>
<br>
Then if any new method is added, the AbstractResource
implementation should try to provide a reasonable default
that works (but is possibly not as efficient as a specific
implementation).<br>
As a result, any custom Resource that extend
AbstractResource needed be changed immediately (but might
want to in time to implement a more efficient
implementation).<br>
<br>
And, more importantly, we don't break binary backwards
compatibility on *api (unless they implemented Resource
directly)<br>
so less chance of "impossible to fix" if you have a
project with a dependency A and B<br>
where A and B themselves depend on different drools
versions,<br>
as you can just use the "highest version" between those 2
dependencies.<br>
<br>
Op 12-09-11 07:51, Mark Proctor schreef:
<div>
<div class="h5">
<blockquote type="cite"> On 12/09/2011 06:36, Esteban
Aliverti wrote:
<blockquote type="cite">Ok, I thought #droolsdev was
ok too. Sorry about that.
<div>The idea to have a 'name' and a 'description'
attribute in <Resource> elements inside a
change-set is to tag them or to add them some
human-friendly information so you can refer to
it not using the URL or the name of the asset
(could be duplicated in different packages), but
with a name and a description.</div>
<div>These changes are 100% end-users oriented,
that is why I put those attributes in API. End
users applications (like Guvnor) could take
advantages on these new attributes.</div>
</blockquote>
You can add them to the xml, and have that set them
on the InternalResource. We can migrate to public
apis over time, I just want people to take a much
more conservative outlook on -api changes.<br>
<br>
Mark<br>
<blockquote type="cite">
<div><br>
</div>
<div>So, a change-set now could look like this
(the new attributes are not mandatory):</div>
<div><br>
</div>
<div>
<div><change-set> </div>
<div> <add></div>
<div> <resource <b>name="Loan Rules"
description="Rules about loans"</b>
type="DRL" source="<a moz-do-not-send="true"
href="http://someHost:1234/someDRLResource.drl"
target="_blank">http://someHost:1234/someDRLResource.drl</a>"/>
</div>
<div> <resource <b>name="Risk Rules"
description="Rules about Risk evaluation"</b>
type="DRL" source="<a moz-do-not-send="true"
href="http://someHost:1234/someOtherDRLResource.drl"
target="_blank">http://someHost:1234/someOtherDRLResource.drl</a>"/></div>
<div> </add></div>
<div></change-set></div>
</div>
<div><br>
</div>
<div>These attributes can also be used in Spring's
configuration:</div>
<div><br>
</div>
<div>
<div><drools:kbase id="kbase1"
node="node1"></div>
<div> <drools:resources> </div>
<div> <resource <b>name="Loan Rules"
description="Rules about loans"</b>
type="DRL" source="<a moz-do-not-send="true"
href="http://someHost:1234/someDRLResource.drl"
target="_blank">http://someHost:1234/someDRLResource.drl</a>"/>
</div>
<div> <resource <b>name="Risk Rules"
description="Rules about Risk evaluation"</b>
type="DRL" source="<a moz-do-not-send="true"
href="http://someHost:1234/someOtherDRLResource.drl"
target="_blank">http://someHost:1234/someOtherDRLResource.drl</a>"/>
</div>
<div> </drools:resources></div>
<div></drools:kbase></div>
</div>
<div><br>
</div>
<div>WDYT?<br clear="all">
<br>
</div>
<div>Best Regards,</div>
<div><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 Mon, Sep 12, 2011 at
6:25 AM, Mark Proctor <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:mproctor@codehaus.org"
target="_blank">mproctor@codehaus.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:
0pt 0pt 0pt 0.8ex; border-left: 1px solid
rgb(204, 204, 204); padding-left: 1ex;">
Shoudn't name and description be on
InternalResource, not on Resource?<br>
<br>
I think it's time to put a restriction on
changes to "-api". Feel free<br>
to change core/compiler etc, but if you want
to change -api we'll need<br>
to propose it here.<br>
<br>
Mark<br>
<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org"
target="_blank">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>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
rules-dev mailing list
<a moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<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>
</pre>
</blockquote>
<br>
<pre><fieldset></fieldset>
_______________________________________________
rules-dev mailing list
<a moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<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>
</pre>
</blockquote>
<br>
</div>
</div>
<pre cols="72">--
With kind regards,
Geoffrey De Smet</pre>
</div>
<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>
</blockquote>
</div>
<br>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
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>
<pre class="moz-signature" cols="72">--
With kind regards,
Geoffrey De Smet</pre>
</body>
</html>