[rules-dev] Rule Dependency Generator
Greg Barton
greg_barton at yahoo.com
Thu Oct 9 13:45:46 EDT 2008
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 <sidangrish at gmail.com> wrote:
> From: Siddharth Angrish <sidangrish at gmail.com>
> Subject: Re: [rules-dev] Rule Dependency Generator
> To: "Rules Dev List" <rules-dev at lists.jboss.org>
> 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 at 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 at redhat.com
> >> <mailto:trikkola at 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/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
> >> <mproctor at codehaus.org
> <mailto:mproctor at codehaus.org>
> >> <mailto:mproctor at codehaus.org
> >>
> >>
> <mailto:mproctor at 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 at lists.jboss.org
> >>
> <mailto:rules-dev at lists.jboss.org>
> >>
> <mailto:rules-dev at lists.jboss.org
> >>
> <mailto:rules-dev at lists.jboss.org>>
> >>
> >>
> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------
> >>
> >>
> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev at lists.jboss.org
> >>
> <mailto:rules-dev at lists.jboss.org>
> >>
> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------
> >>
> >>
> >>
> >>
> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> >>
> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> >>
> >>
> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> >>
> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> >>
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
More information about the rules-dev
mailing list