Hi I'm currently working on an implementation of a new type of problem type namely Warnings, to solve the following JIRA's: JBRULES-3124, JBRULES-3063, JBRULES-2730 One of the JIRA's deal with the detection of duplicate rules and another with detection of duplicate functions. The question I have is in regards to this is, the current implementation allows for rules and functions to be overridden by functions and rules defined in different .drl files. In order to not break backwards compatibility and allow people to continue with this behavior we could just create a warning for these types of issues which is reported through a new getProblems(ProblemType... problemTypes) to get the problem types you are interested in, we will leave the legacy method getErrors() for backward compatibility. Another approach or complementary approach is to for certain types of these Warnings configure the compiler to be more or less strict, which in turn would switch the Type of these issues from Warning to Error. Is this something that's desirable or would it be sufficient to just report these issues as warnings and leave the responsibility to the user to halt execution if certain Warnings exists? Kind Regards Mikael (gwendo) _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Sounds like a sensible plan, but generally I’d recommend erring on the side of restrictiveness and require the user to explicitly state when they want support for a more unusual feature. The reason for this is people new to drools should be strongly encouraged not to do potentially undesirable things, it’s much easier to choose to enable things you actually want than to choose to restrict behaviours you have no knowledge of!**** ** ** Thomas**** ** ** *From:* rules-dev-bounces(a)lists.jboss.org [mailto: rules-dev-bounces(a)lists.jboss.org] *On Behalf Of *Edson Tirelli *Sent:* 25 August 2011 01:03 *To:* Rules Dev List *Subject:* Re: [rules-dev] PackageBuilder Warnings question**** ** ** ** ** Hi Mikael,**** ** ** One idea would be to define severities for compilation messages... could be 1..3, could be INFO, WARN, ERROR, etc. Each problem would have a default priority and in an ideal world, the user could override this priority (like you can do it in eclipse). So, for instance, a rule update could have a default severity of INFO, but if the user does not use dynamic rule updates, he would be able to define it as severity ERROR. **** ** ** ERRORS would always prevent execution, while warnings and infos would be reported, but not prevent usage.**** ** ** This is my opinion would be a great step forward compared to what we have today.**** ** ** What do you think?**** ** ** Thanks,**** Edson **** 2011/8/24 Mikael Lönneberg <emil(a)snickeboa.com&gt;**** Hi I'm currently working on an implementation of a new type of problem type namely Warnings, to solve the following JIRA's: **** JBRULES-3124, JBRULES-3063, JBRULES-2730**** ** ** One of the JIRA's deal with the detection of duplicate rules and another with detection of duplicate functions.**** The question I have is in regards to this is, the current implementation allows for rules and functions to be overridden by functions and rules defined in different .drl files.**** In order to not break backwards compatibility and allow people to continue with this behavior we could just create a warning for these types of issues which is reported through a new getProblems(ProblemType... problemTypes) to get the problem types you are interested in, we will leave the legacy method getErrors() for backward compatibility. Another approach or complementary approach is to for certain types of these Warnings configure the compiler to be more or less strict, which in turn would switch the Type of these issues from Warning to Error. Is this something that's desirable or would it be sufficient to just report these issues as warnings and leave the responsibility to the user to halt execution if certain Warnings exists?** ** ** ** Kind Regards**** ** ** Mikael (gwendo)**** _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev**** **** ** ** -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com**** ------------------------------ ************************************************************************************** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster(a)nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 ************************************************************************************** _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Hi Edson, I think we are actually in agreement here as the ProblemTypes could easily be renamed to Severity instead.. I will have to think through how to expose the different message types that should be possible to override. Kind Regards Mikael On Thu, Aug 25, 2011 at 2:02 AM, Edson Tirelli <ed.tirelli(a)gmail.com&gt;wrote: > > Hi Mikael, > > One idea would be to define severities for compilation messages... > could be 1..3, could be INFO, WARN, ERROR, etc. Each problem would have a > default priority and in an ideal world, the user could override this > priority (like you can do it in eclipse). So, for instance, a rule update > could have a default severity of INFO, but if the user does not use dynamic > rule updates, he would be able to define it as severity ERROR. > > ERRORS would always prevent execution, while warnings and infos would > be reported, but not prevent usage. > > This is my opinion would be a great step forward compared to what we > have today. > > What do you think? > > Thanks, > Edson > > 2011/8/24 Mikael Lönneberg <emil(a)snickeboa.com&gt; > >> Hi I'm currently working on an implementation of a new type of problem >> type namely Warnings, to solve the following JIRA's: >> JBRULES-3124, JBRULES-3063, JBRULES-2730 >> >> One of the JIRA's deal with the detection of duplicate rules and another >> with detection of duplicate functions. >> The question I have is in regards to this is, the current implementation >> allows for rules and functions to be overridden by functions and rules >> defined in different .drl files. >> In order to not break backwards compatibility and allow people to >> continue with this behavior we could just create a warning for these types >> of issues which is reported through a new getProblems(ProblemType... >> problemTypes) to get the problem types you are interested in, we will leave >> the legacy method getErrors() for backward compatibility. Another approach >> or complementary approach is to for certain types of these Warnings >> configure the compiler to be more or less strict, which in turn would switch >> the Type of these issues from Warning to Error. Is this something that's >> desirable or would it be sufficient to just report these issues as warnings >> and leave the responsibility to the user to halt execution if certain >> Warnings exists? >> >> Kind Regards >> >> Mikael (gwendo) >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss by Red Hat @ www.jboss.com > > _______________________________________________ > 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