Done:<div><a href="https://github.com/droolsjbpm/droolsjbpm-knowledge/pull/14">https://github.com/droolsjbpm/droolsjbpm-knowledge/pull/14</a></div><div><a href="https://github.com/droolsjbpm/drools/pull/61">https://github.com/droolsjbpm/drools/pull/61</a></div>
<div><a href="https://github.com/droolsjbpm/droolsjbpm-integration/pull/7">https://github.com/droolsjbpm/droolsjbpm-integration/pull/7</a><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 10:32 AM, Mark Proctor <span dir="ltr"><<a 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 bgcolor="#FFFFFF" text="#000000"><div class="im">
On 12/09/2011 09:18, Esteban Aliverti wrote:
<blockquote 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>
</blockquote></div>
At some point geoffrey is going to add a -internal-apior something
like like. The idea is to use this as a staging ground to allow end
user apis to mature to stability.<br>
<br>
At the moment the whole stuff around changesets, resources etc is
still very immature and i'm not sure we have the entire design
right. If you notice in the changeset javadocs I tell people to only
use the xml change notation and not the api at this stage. I want to
see us mature this futher before we start locking apis in granite.
We still have a lot work to do on deployment, especially on
changesets.<br>
<br>
For your current use case the user should never be accessing the
resulting Resource instances anyway, it's applied via the xml. If
there is a problem that information becomes part of an informational
error log. They aren't going to inspect resulting resource
instances.<br><font color="#888888">
<br>
Mark</font><div><div></div><div class="h5"><br>
<blockquote type="cite">
<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" target="_blank">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">
<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>
<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" 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>
<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>
</div></div></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>