Hi Toni, I checked out the drools-verifier code. For a little acclimatization I went through a few files. Looks like Verifier.java is the main class for verifier tool. I went on to check how the Consequences are being handled but could only find the interface Consequence.java and TextConsequence.java which doesn't do too much. It would be helpful to have some higher level description of the relevant class relationships. (who's who). Also, it may be helpful to know how to build this code and how to run it. I checked out the code from the url: http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-verifier/ but could not get any build script or instructions. I hope I am going in the right direction. Siddharth On Mon, Oct 6, 2008 at 6:56 PM, Toni Rikkola <trikkola(a)redhat.com <mailto:trikkola@redhat.com>> wrote: Hi Siddharth Your work sounds interesting and I would like to hear more about it. Looks like your version is smarter with dependencies. The report data is used in Guvnor and in the HTML-report, but it can also be retrieved as XML or java objects. The HTML-report lists all the fields, rules and object types. So you can see what rules use certain object type and the field view shows what values are compared against the field. This dependency data is also used in the verification rules when searching for issues from the rule base. Like Mark said, the verifier is still quite blind for the RHS. Right now it just handles it as a string. So it can't really tell what objects were modified and how. This information is important to solve what rule creates or modifies facts to satisfy another rule. This dependency data can then again be used to find subsumption, loops ect. I hope that we can discuss about this soon. Toni Mark Proctor wrote: Siddharth Angrish wrote: Hi Mark I went through the RuleAnalytics Module document. It looks like there is a good compatibility between your visions of Rule Analysis and our rule dependency generation work. I'll be excited to further develop and integrate my work with drools-verifier module code. Just a short summary of how I had approached the problem: We have long ruleflow which consists of other ruleflows, ruleflow groups, split conditions. Using drools API I was able to traverse through the main ruleflow including (recursively) constituent nodes. So at any node I knew which rules are relevant. Now, to find out dependency between rules I required very intricate information about any given rule. I could not find sufficient drools APIs to get this information. There are methods to get LHS and RHS of a rule but they do not give information about individual attributes. For RHS its more worse. No textual information was availabe about it. (I am using 4.0.7 and I had even posted my questions on Drools user mailing list) As a result, I wrote my own .drl file parser using javacc (which was very interesting to do) and got whatever information I required. Now I knew which rule modifies which attribute (and of which class) and which rule uses what atrributes in its conditional part. Its much easier to get dependecy sequence now. I know a few cases where this approach might produce a false dependency sequence but using other rule-flow(salience, agenda) information can help us avoid that. Now, how shall we go about it? I have installed irc on my system and I think I require some url to be able to connect to you guys. The details of connecting with irc are here: http://www.jboss.org/drools/irc.html you want to speak to Rikkola online if you see him. We don't want to add another DRL parser, as we already build up an internal tree - including consequence. So in the drools-verifier you already see how we build the descr tree, although that doesn't yet have an AST for the consequence, however we have java analysier that currently does (using antlr) and this and pulls out used identifiers: http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-compiler/src/m... We also extended our antlr grammar to understand the modify(...) {......} keyword. So you should be able to re-use the code inside of java expr analyzer to rewrite your existing stuff and also reusing our existing descr tree. Hopefully Toni Rikolla can help you with this online. Mark Siddharth On Sun, Oct 5, 2008 at 7:40 PM, Mark Proctor <mproctor(a)codehaus.org <mailto:mproctor@codehaus.org> <mailto:mproctor@codehaus.org <mailto:mproctor@codehaus.org>>> wrote: Drools 5.0 has the drools-verifier. This does a variety of verifications and analysis, like where class fields are used, gap analysis etc. The Guvnor BRMS can produce HTML reports for this information. Subsumption isn't done yet, we needed to analys the consequences for update/modify to try and detect potential impacted rules - this is also needed to detect which rules depend on other rules. http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-verifier/ http://wiki.jboss.org/wiki/RuleAnalyticsModule So we would love to have your work as additions to this, but it will need to be integrated with the existing drools-verifier module code and the HTML reporting - can you make that happen? It would be ideal, as it then means your code is part of the main project and will be maintained and improved by the community. Maybe you could pop onto irc, and chat to us about it more? http://www.jboss.org/drools/irc.html Do you have any visualisation plans? If on the web GWT-Diagram is turning out to be a great tool http://code.google.com/p/gwt-diagrams/ Mark Sangrish wrote: Hi I have been using Drools Rules Engine in our application for past couple of weeks. One of the requirements in our project was to let a user (anyone who is writing/analysing the rules) find out what other rules a given rule depends upon. There were a few kinds of dependencies: 1) Object Attribute dependency: The attributes of an object being used in the conditional part of a rule might be getting modified in the consequence part of another rule. We wanted all such rules with each rule having its own dependency list. 2) Rule Salience based dependency. A rule having lower salience should be executed only after a higher (if any) salience rule has already been executed. 3) Dependency caused by a specific Rule flow. Rules in a ruleflow group should be executed only if (if any) Split condition gets satisfied. 4) Agenda flow dependency (i.e., one agenda following another) We could not find much support for this in the Drools API. Hence we decided to write our own dependency generator. The tool we are writing caters to first 3 dependencies. We might even handle the 4th one. Since Drools is open source, we thought of contributing our bit towards its development. If the drools team wants I can happily work with them on getting this functionality plugged in the Drools system. Thanks Siddharth _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> <mailto:rules-dev@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 _______________________________________________ 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

From: Siddharth Angrish <sidangrish(a)gmail.com&gt; Subject: Re: [rules-dev] Rule Dependency Generator To: "Rules Dev List" <rules-dev(a)lists.jboss.org&gt; Date: Thursday, October 9, 2008, 12:11 PM I was building the full code and encountered the following error at the end. Throughout the whole install/build process everything looked fine. I am not sure though if it has built drools-verifier/compiler/core correctly. (I had attached the build process logs in a separate mail to the group but because of the size the mail was not accepted by the moderator) Siddharth ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.drools.dataloaders.jaxb.DroolsJaxbTest Tests run: 3, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 2.734 sec <<< FAILURE! Results : Tests in error: testDirectRoot(org.drools.dataloaders.jaxb.DroolsJaxbTest) testNestedIterable(org.drools.dataloaders.jaxb.DroolsJaxbTest) Tests run: 3, Failures: 0, Errors: 2, Skipped: 0 [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] There are test failures. Please refer to C:\Users\sangrish\workspace\drools-full-code\drools-dataloaders\drools-dataloaders-jaxb\target\surefire- reports for the individual test results. [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 6 minutes 29 seconds [INFO] Finished at: Wed Oct 08 21:51:35 EDT 2008 [INFO] Final Memory: 26M/63M [INFO] ------------------------------------------------------------------------ On Tue, Oct 7, 2008 at 11:46 AM, Toni Rikkola <trikkola(a)redhat.com&gt; wrote: > Hi > > Yes, the Verifier.java is the main class. At the moment > TextConsequence.java and Consequence.java are the only classes that handle > the RHS. Verifier uses these in the drl-files, but it just does a simple > string comparison. > > Verify objects (classes that extend VerifierComponent) contain data about > the relations that they have. Each object is given an id and this id is used > to indicate the relations. Each object also knows the rule name and rule id > that it belongs to. Patterns have object type id's and Restrictions have > field id's, with this information you can find out where object types or > fields are used. All this information is stored in VerifierDataMaps and to > get for example all the restrictions that use certain field you need to know > the field id and call getRestrictionsByFieldId(int fieldId) or do this > search in verifier rules where the same objects are as facts. > > The verifier executes in three phases. > > First phase finds the dependencies. Which field belongs to which object > type and what rules contain what object types and flattens the AST so that > it can be more easily used in the verifying rules. This phase also finds out > the different possibilities that can satisfy patterns and rules. Main class > for this phase is PackageDescrFlattener, it stores the data to VerifierData. > > The second phase is done with drools rules. It uses flattened AST and > dependency facts to solve object relationships and find issues. > Relationships that are found here are overlaps/partial redundancies, > redundancies, incompatibilities and opposites. These can happen between > rules, patterns or restrictions. Issues are stored using VerifierResult > class. > > Third phase just takes the conclusions from working memory and reports them > in the format that you want. > > Toni > > Siddharth Angrish wrote: > >> >> Hi Toni, >> >> I checked out the drools-verifier code. For a little >> acclimatization I went through a few files. Looks like >> Verifier.java is the main >> class for verifier tool. I went on to check how the Consequences >> are being handled but could only find the interface >> Consequence.java and >> TextConsequence.java which doesn't do too much. >> It would be helpful to have some higher level description of the >> relevant class relationships. (who's who). >> Also, it may be helpful to know how to build this code and how to >> run it. I checked out the code from the url: >> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-verifier/ >> but could not get any build script or instructions. >> >> I hope I am going in the right direction. >> >> Siddharth >> >> >> >> >> >> >> On Mon, Oct 6, 2008 at 6:56 PM, Toni Rikkola <trikkola(a)redhat.com >> <mailto:trikkola@redhat.com>> wrote: >> >> Hi Siddharth >> >> Your work sounds interesting and I would like to hear more >> about it. Looks like your version is smarter with dependencies. >> >> The report data is used in Guvnor and in the HTML-report, but >> it can also be retrieved as XML or java objects. >> >> The HTML-report lists all the fields, rules and object types. >> So you can see what rules use certain object type and the >> field view shows what values are compared against the field. >> This dependency data is also used in the verification rules >> when searching for issues from the rule base. >> >> Like Mark said, the verifier is still quite blind for the RHS. >> Right now it just handles it as a string. So it can't really >> tell what objects were modified and how. This information is >> important to solve what rule creates or modifies facts to >> satisfy another rule. This dependency data can then again be >> used to find subsumption, loops ect. >> >> I hope that we can discuss about this soon. >> >> Toni >> >> Mark Proctor wrote: >> >> Siddharth Angrish wrote: >> >> Hi Mark >> >> I went through the RuleAnalytics Module document. >> It looks like there is a good compatibility between >> your visions of Rule Analysis and our rule dependency >> generation work. I'll be excited to further develop >> and integrate my work with drools-verifier module code. >> >> Just a short summary of how I had approached the problem: >> >> We have long ruleflow which consists of other >> ruleflows, ruleflow groups, split conditions. Using >> drools API I was >> able to traverse through the main ruleflow including >> (recursively) constituent nodes. So at any node I knew >> which rules >> are relevant. Now, to find out dependency between >> rules I required very intricate information about any >> given rule. I could not >> find sufficient drools APIs to get this information. >> There are methods to get LHS and RHS of a rule but >> they do not give information about individual >> attributes. For RHS its more worse. No textual >> information was availabe about it. (I am using 4.0.7 >> and I had even posted my questions on Drools user >> mailing list) >> >> As a result, I wrote my own .drl file parser using >> javacc (which was very interesting to do) and got >> whatever information I required. >> Now I knew which rule modifies which attribute (and of >> which class) and which rule uses what atrributes in >> its conditional part. Its much easier to get dependecy >> sequence now. I know a few cases where this approach >> might produce a false dependency sequence but using >> other rule-flow(salience, agenda) information can help >> us avoid that. >> >> Now, how shall we go about it? I have installed irc >> on my system and I think I require some url to be able >> to connect to you guys. >> >> The details of connecting with irc are here: >> http://www.jboss.org/drools/irc.html >> >> you want to speak to Rikkola online if you see him. >> >> We don't want to add another DRL parser, as we already >> build up an internal tree - including consequence. So in >> the drools-verifier you already see how we build the descr >> tree, although that doesn't yet have an AST for the >> consequence, however we have java analysier that currently >> does (using antlr) and this and pulls out used identifiers: >> >> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-compiler/src/m... >> >> We also extended our antlr grammar to understand the >> modify(...) {......} keyword. So you should be able to >> re-use the code inside of java expr analyzer to rewrite >> your existing stuff and also reusing our existing descr >> tree. Hopefully Toni Rikolla can help you with this online. >> >> Mark >> >> >> Siddharth >> >> >> On Sun, Oct 5, 2008 at 7:40 PM, Mark Proctor >> <mproctor(a)codehaus.org <mailto:mproctor@codehaus.org> >> <mailto:mproctor@codehaus.org >> >> <mailto:mproctor@codehaus.org>>> wrote: >> >> Drools 5.0 has the drools-verifier. This does a >> variety of >> verifications and analysis, like where class fields >> are used, gap >> analysis etc. The Guvnor BRMS can produce HTML >> reports for this >> information. Subsumption isn't done yet, we needed >> to analys the >> consequences for update/modify to try and detect >> potential >> impacted rules - this is also needed to detect >> which rules depend >> on other rules. >> >> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-verifier/ >> http://wiki.jboss.org/wiki/RuleAnalyticsModule >> >> So we would love to have your work as additions to >> this, but it >> will need to be integrated with the existing >> drools-verifier >> module code and the HTML reporting - can you make >> that happen? It >> would be ideal, as it then means your code is part >> of the main >> project and will be maintained and improved by the >> community. >> >> Maybe you could pop onto irc, and chat to us about >> it more? >> http://www.jboss.org/drools/irc.html >> >> Do you have any visualisation plans? If on the web >> GWT-Diagram is >> turning out to be a great tool >> http://code.google.com/p/gwt-diagrams/ >> >> Mark >> >> >> >> Sangrish wrote: >> >> Hi >> >> I have been using Drools Rules Engine in >> our application >> for past >> couple of weeks. >> One of the requirements in our project was to >> let a user >> (anyone who is >> writing/analysing the rules) find out >> what other rules a given rule depends upon. >> There were a few >> kinds of >> dependencies: >> 1) Object Attribute dependency: The attributes >> of an object >> being used in >> the conditional part of a rule >> might be getting modified in the consequence >> part of >> another rule. We >> wanted all such rules with each rule having its own >> dependency list. >> 2) Rule Salience based dependency. A rule >> having lower >> salience should be >> executed only after a higher (if any) salience >> rule has >> already been >> executed. >> 3) Dependency caused by a specific Rule flow. >> Rules in a >> ruleflow group >> should be executed only if (if any) Split >> condition gets >> satisfied. >> 4) Agenda flow dependency (i.e., one agenda >> following another) >> We could not find much support for this in >> the Drools API. >> Hence we >> decided to write our own dependency generator. >> The tool we >> are writing >> caters to first 3 dependencies. We might even >> handle the 4th >> one. Since Drools is open source, we thought of >> contributing our bit towards >> its development. If the drools team wants I can >> happily work >> with them on >> getting this functionality plugged in the >> Drools system. >> >> >> Thanks >> Siddharth >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> <mailto:rules-dev@lists.jboss.org> >> <mailto:rules-dev@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 >> >> >> _______________________________________________ >> 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 > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Hi Toni I ran the JUnit test case : VerifierTest.java. It ran successfully but I was expecting it to generate some html (or something) report of what verification it could generate or any analysis. It just says yes/no. Which test case shall I run to see what output(and where) is being generated by the current "verification" code. Also, the input file "Misc3.drl" is present in more than 1 place and I am not sure where does the test case pick it from. Thanks Siddharth On Tue, Oct 7, 2008 at 2:46 PM, Toni Rikkola <trikkola(a)redhat.com <mailto:trikkola@redhat.com>> wrote: Hi Yes, the Verifier.java is the main class. At the moment TextConsequence.java and Consequence.java are the only classes that handle the RHS. Verifier uses these in the drl-files, but it just does a simple string comparison. Verify objects (classes that extend VerifierComponent) contain data about the relations that they have. Each object is given an id and this id is used to indicate the relations. Each object also knows the rule name and rule id that it belongs to. Patterns have object type id's and Restrictions have field id's, with this information you can find out where object types or fields are used. All this information is stored in VerifierDataMaps and to get for example all the restrictions that use certain field you need to know the field id and call getRestrictionsByFieldId(int fieldId) or do this search in verifier rules where the same objects are as facts. The verifier executes in three phases. First phase finds the dependencies. Which field belongs to which object type and what rules contain what object types and flattens the AST so that it can be more easily used in the verifying rules. This phase also finds out the different possibilities that can satisfy patterns and rules. Main class for this phase is PackageDescrFlattener, it stores the data to VerifierData. The second phase is done with drools rules. It uses flattened AST and dependency facts to solve object relationships and find issues. Relationships that are found here are overlaps/partial redundancies, redundancies, incompatibilities and opposites. These can happen between rules, patterns or restrictions. Issues are stored using VerifierResult class. Third phase just takes the conclusions from working memory and reports them in the format that you want. Toni Siddharth Angrish wrote: Hi Toni, I checked out the drools-verifier code. For a little acclimatization I went through a few files. Looks like Verifier.java is the main class for verifier tool. I went on to check how the Consequences are being handled but could only find the interface Consequence.java and TextConsequence.java which doesn't do too much. It would be helpful to have some higher level description of the relevant class relationships. (who's who). Also, it may be helpful to know how to build this code and how to run it. I checked out the code from the url: http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-verifier/ but could not get any build script or instructions. I hope I am going in the right direction. Siddharth On Mon, Oct 6, 2008 at 6:56 PM, Toni Rikkola <trikkola(a)redhat.com <mailto:trikkola@redhat.com> <mailto:trikkola@redhat.com <mailto:trikkola@redhat.com>>> wrote: Hi Siddharth Your work sounds interesting and I would like to hear more about it. Looks like your version is smarter with dependencies. The report data is used in Guvnor and in the HTML-report, but it can also be retrieved as XML or java objects. The HTML-report lists all the fields, rules and object types. So you can see what rules use certain object type and the field view shows what values are compared against the field. This dependency data is also used in the verification rules when searching for issues from the rule base. Like Mark said, the verifier is still quite blind for the RHS. Right now it just handles it as a string. So it can't really tell what objects were modified and how. This information is important to solve what rule creates or modifies facts to satisfy another rule. This dependency data can then again be used to find subsumption, loops ect. I hope that we can discuss about this soon. Toni Mark Proctor wrote: Siddharth Angrish wrote: Hi Mark I went through the RuleAnalytics Module document. It looks like there is a good compatibility between your visions of Rule Analysis and our rule dependency generation work. I'll be excited to further develop and integrate my work with drools-verifier module code. Just a short summary of how I had approached the problem: We have long ruleflow which consists of other ruleflows, ruleflow groups, split conditions. Using drools API I was able to traverse through the main ruleflow including (recursively) constituent nodes. So at any node I knew which rules are relevant. Now, to find out dependency between rules I required very intricate information about any given rule. I could not find sufficient drools APIs to get this information. There are methods to get LHS and RHS of a rule but they do not give information about individual attributes. For RHS its more worse. No textual information was availabe about it. (I am using 4.0.7 and I had even posted my questions on Drools user mailing list) As a result, I wrote my own .drl file parser using javacc (which was very interesting to do) and got whatever information I required. Now I knew which rule modifies which attribute (and of which class) and which rule uses what atrributes in its conditional part. Its much easier to get dependecy sequence now. I know a few cases where this approach might produce a false dependency sequence but using other rule-flow(salience, agenda) information can help us avoid that. Now, how shall we go about it? I have installed irc on my system and I think I require some url to be able to connect to you guys. The details of connecting with irc are here: http://www.jboss.org/drools/irc.html you want to speak to Rikkola online if you see him. We don't want to add another DRL parser, as we already build up an internal tree - including consequence. So in the drools-verifier you already see how we build the descr tree, although that doesn't yet have an AST for the consequence, however we have java analysier that currently does (using antlr) and this and pulls out used identifiers: http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-compiler/src/m... We also extended our antlr grammar to understand the modify(...) {......} keyword. So you should be able to re-use the code inside of java expr analyzer to rewrite your existing stuff and also reusing our existing descr tree. Hopefully Toni Rikolla can help you with this online. Mark Siddharth On Sun, Oct 5, 2008 at 7:40 PM, Mark Proctor <mproctor(a)codehaus.org <mailto:mproctor@codehaus.org> <mailto:mproctor@codehaus.org <mailto:mproctor@codehaus.org>> <mailto:mproctor@codehaus.org <mailto:mproctor@codehaus.org> <mailto:mproctor@codehaus.org <mailto:mproctor@codehaus.org>>>> wrote: Drools 5.0 has the drools-verifier. This does a variety of verifications and analysis, like where class fields are used, gap analysis etc. The Guvnor BRMS can produce HTML reports for this information. Subsumption isn't done yet, we needed to analys the consequences for update/modify to try and detect potential impacted rules - this is also needed to detect which rules depend on other rules. http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-verifier/ http://wiki.jboss.org/wiki/RuleAnalyticsModule So we would love to have your work as additions to this, but it will need to be integrated with the existing drools-verifier module code and the HTML reporting - can you make that happen? It would be ideal, as it then means your code is part of the main project and will be maintained and improved by the community. Maybe you could pop onto irc, and chat to us about it more? http://www.jboss.org/drools/irc.html Do you have any visualisation plans? If on the web GWT-Diagram is turning out to be a great tool http://code.google.com/p/gwt-diagrams/ Mark Sangrish wrote: Hi I have been using Drools Rules Engine in our application for past couple of weeks. One of the requirements in our project was to let a user (anyone who is writing/analysing the rules) find out what other rules a given rule depends upon. There were a few kinds of dependencies: 1) Object Attribute dependency: The attributes of an object being used in the conditional part of a rule might be getting modified in the consequence part of another rule. We wanted all such rules with each rule having its own dependency list. 2) Rule Salience based dependency. A rule having lower salience should be executed only after a higher (if any) salience rule has already been executed. 3) Dependency caused by a specific Rule flow. Rules in a ruleflow group should be executed only if (if any) Split condition gets satisfied. 4) Agenda flow dependency (i.e., one agenda following another) We could not find much support for this in the Drools API. Hence we decided to write our own dependency generator. The tool we are writing caters to first 3 dependencies. We might even handle the 4th one. Since Drools is open source, we thought of contributing our bit towards its development. If the drools team wants I can happily work with them on getting this functionality plugged in the Drools system. Thanks Siddharth _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> <mailto:rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>> <mailto:rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org> <mailto:rules-dev@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> <mailto:rules-dev@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> <mailto:rules-dev@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> <mailto:rules-dev@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 ------------------------------------------------------------------------ _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev