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 https://lists.jboss.org/mailman/listinfo/rules-dev

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 > 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

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

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.spam(a)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 <mproctor(a)codehaus.org&gt;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 >> 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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev