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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> 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/main/java/org/drools/rule/builder/dialect/java/JavaExprAnalyzer.java >> >> 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 >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> <mailto:[EMAIL PROTECTED] >> >> <mailto:[EMAIL PROTECTED]>>> 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 >> [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>> >> >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rules-dev mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> rules-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> _______________________________________________ >> rules-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rules-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev >
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
