Re: [rules-dev] Resource getName getDescription

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(a)gmail.com <mailto:ge0ffrey.spam@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(a)codehaus.org <mailto:mproctor@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/rules-dev > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev -- With kind regards, Geoffrey De Smet _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev