Done: https://github.com/droolsjbpm/droolsjbpm-knowledge/pull/14 https://github.com/droolsjbpm/drools/pull/61 https://github.com/droolsjbpm/droolsjbpm-integration/pull/7
Best Regards, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Esteban Aliverti - Developer @ http://www.plugtree.com - Blog @ http://ilesteban.wordpress.com On Mon, Sep 12, 2011 at 10:32 AM, Mark Proctor <mproc...@codehaus.org>wrote: > On 12/09/2011 09:18, Esteban Aliverti wrote: > > 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. > > 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. > > 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. > > 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. > > Mark > > > 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 > listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > 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
