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 href="http://www.plugtree.com" target="_blank">http://www.plugtree.com </a><br>- Blog @ <a 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 href="mailto:ge0ffrey.spam@gmail.com">ge0ffrey.spam@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<u></u>
<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></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 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 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 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 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 href="http://www.plugtree.com" target="_blank">http://www.plugtree.com
</a><br>
- Blog @ <a 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 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 href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
<a 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 href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a 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 href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a 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 href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a 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>