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 - Blog @ http://ilesteban.wordpress.com On Mon, Sep 12, 2011 at 9:04 AM, Geoffrey De Smet <ge0ffrey.s...@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 > - Blog @ http://ilesteban.wordpress.com > > > On Mon, Sep 12, 2011 at 6:25 AM, Mark Proctor <mproc...@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> > > > > _______________________________________________ > rules-dev mailing > listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > rules-dev mailing > listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev > > > -- > With kind regards, > Geoffrey De Smet > > > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > >
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
