You can get around running the tests by using this command line switch: -Dmaven.test.skip=true
But it's up to the devs as to whether the test failure is significant. --- On Thu, 10/9/08, Siddharth Angrish <[EMAIL PROTECTED]> wrote: > From: Siddharth Angrish <[EMAIL PROTECTED]> > Subject: Re: [rules-dev] Rule Dependency Generator > To: "Rules Dev List" <[email protected]> > 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 > <[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 _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
