[rules-dev] Resource getName getDescription
Geoffrey De Smet
ge0ffrey.spam at gmail.com
Mon Sep 12 04:31:49 EDT 2011
The "expose them in core first, later in api" is a good thing. +1 there.
I was talking about a different aspect:
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.
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).
Op 12-09-11 10:18, Esteban Aliverti schreef:
> Ok, I will move these attributes to drools-core (InternalResource).
> Later, we can think about move them to drools-api.
> 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).
> But, as a general solution, I'm not against the implementation of new
> features in core first and the exposure on api later.
>
> Best Regards,
>
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> Esteban Aliverti
> - Developer @ http://www.plugtree.com <http://www.plugtree.com>
> - Blog @ http://ilesteban.wordpress.com
>
>
> On Mon, Sep 12, 2011 at 9:04 AM, Geoffrey De Smet
> <ge0ffrey.spam at gmail.com <mailto:ge0ffrey.spam at gmail.com>> wrote:
>
> We could use Abstract* class trick (the Collections api does it
> and I use it a lot in Planner):
>
> drools-api has:
> interface Resource
> abstract class AbstractResource implement Resource
> And the javadoc on interface Resource clearly states that they
> should extend AbstractResource when implementing a custom
> Resource. Same for the reference manual.
> (Similar to interface List and class AbstractList)
>
> 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).
> 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).
>
> And, more importantly, we don't break binary backwards
> compatibility on *api (unless they implemented Resource directly)
> so less chance of "impossible to fix" if you have a project with a
> dependency A and B
> where A and B themselves depend on different drools versions,
> as you can just use the "highest version" between those 2
> dependencies.
>
> Op 12-09-11 07:51, Mark Proctor schreef:
>> On 12/09/2011 06:36, Esteban Aliverti wrote:
>>> Ok, I thought #droolsdev was ok too. Sorry about that.
>>> 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.
>>> 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.
>> 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.
>>
>> Mark
>>>
>>> So, a change-set now could look like this (the new attributes
>>> are not mandatory):
>>>
>>> <change-set>
>>> <add>
>>> <resource *name="Loan Rules" description="Rules about loans"*
>>> type="DRL" source="http://someHost:1234/someDRLResource.drl"/>
>>> <resource *name="Risk Rules" description="Rules about Risk
>>> evaluation"* type="DRL"
>>> source="http://someHost:1234/someOtherDRLResource.drl"/>
>>> </add>
>>> </change-set>
>>>
>>> These attributes can also be used in Spring's configuration:
>>>
>>> <drools:kbase id="kbase1" node="node1">
>>> <drools:resources>
>>> <resource *name="Loan Rules" description="Rules about loans"*
>>> type="DRL" source="http://someHost:1234/someDRLResource.drl"/>
>>> <resource *name="Risk Rules" description="Rules about Risk
>>> evaluation"* type="DRL"
>>> source="http://someHost:1234/someOtherDRLResource.drl"/>
>>> </drools:resources>
>>> </drools:kbase>
>>>
>>> WDYT?
>>>
>>> Best Regards,
>>>
>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>>>
>>> Esteban Aliverti
>>> - Developer @ http://www.plugtree.com <http://www.plugtree.com>
>>> - Blog @ http://ilesteban.wordpress.com
>>>
>>>
>>> On Mon, Sep 12, 2011 at 6:25 AM, Mark Proctor
>>> <mproctor at codehaus.org <mailto:mproctor at codehaus.org>> wrote:
>>>
>>> Shoudn't name and description be on InternalResource, not on
>>> Resource?
>>>
>>> I think it's time to put a restriction on changes to "-api".
>>> Feel free
>>> to change core/compiler etc, but if you want to change -api
>>> we'll need
>>> to propose it here.
>>>
>>> Mark
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110912/4a8041c7/attachment-0001.html
More information about the rules-dev
mailing list