headers
Mark Proctor | 1 Apr 01:11

[rules-dev] Google Summer of Code Deadlines extended

http://blog.athico.com/2008/04/google-summer-of-code-deadlines.html

The GSoC application deadlines have been extended until 1st of April, as detailed here. I preveiously discussed the Drools GSoC projects here. For the lazy I'm listing those below again, so please hurry about get your applications in here:

  • Subversion/CVS and JCR synchronisation. This allows our web based BRMS, called Guvnor, to synchronise it's content with what's used in an IDE, such as Eclipse
  • Eclipse file upload tool with meta-data properties editing. You should be able to right click a file or a folder and upload to the web based Guvnor. Previously uploaded files(assets) should be recognised and uploaded as a modify.
  • SBVR, structured natural language, implementation for Drools. Can do either or both the frontend or the backend.
  • Eclipse tooling enhancements including any of the following: search, refactoring, reformatting.
  • Animate the Rete view to represent network propagation.
  • Improve the DSL capabilities of Drools, supporting more complex grammars.
  • Improve the Guvnor, web based BRMS, to handle the management of more asset types. Including images, video, sound etc. Guvnor involves JCR, Seam and GWT work.
  • Create a Web based process designer for Drools ruleflow using GWT Designer.
  • Web based, GWT, Audit viewer.


Mark
Mark Proctor wrote:
http://blog.athico.com/2008/03/drools-and-google-summer-of-code.html

The Google Summer of Code is beginning. Drools, being a Red Hat project, has to participate under the Fedora banner. So I've put a few project ideas up on the JBoss GSoC page. If you're able to enter as a student please do take a look and don't hesitate to contact if anything interests you.

I've also listed the ideas below, please leave comments if you have any other ideas you think might make good student projects. Or maybe you are a student and you want to propose a GSoC project.

  • Subversion/CVS and JCR synchronisation. This allows our web based BRMS, called Guvnor, to synchronise it's content with what's used in an IDE, such as Eclipse
  • Eclipse file upload tool with meta-data properties editing. You should be able to right click a file or a folder and upload to the web based Guvnor. Previously uploaded files(assets) should be recognised and uploaded as a modify.
  • SBVR, structured natural language, implementation for Drools. Can do either or both the frontend or the backend.
  • Eclipse tooling enhancements including any of the following: search, refactoring, reformatting.
  • Animate the Rete view to represent network propagation.
  • Improve the DSL capabilities of Drools, supporting more complex grammars.
  • Improve the Guvnor, web based BRMS, to handle the management of more asset types. Including images, video, sound etc. Guvnor involves JCR, Seam and GWT work.
  • Create a Web based process designer for Drools ruleflow using GWT Designer.

    • Mark
    _______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
    Permalink | Reply | 0 comments |
    headers
    JoelA | 2 Apr 09:33

    Re: [rules-dev] BRMS and Fit for Rules

    
Is there anything more to add on this? 

We are in the same situation as Paul and are considering elaborating
fit-for-rules or writing our own fit/fitnesse stuff (maybe more like
Servicefixture). We hope to have business types take care of testing their
rules based on pkgs dev provides them.

I've also read this post:

http://blog.athico.com/2007/12/testing-rules-introduction.html

What's the status on this 'integrated testing tool' mentioned in the blog?

Joel 

Paul Browne wrote:
> 
> As part of the some 'stuff' (you may be able to guess!) found myself r
> needing to integrate FIT for Rules and the BRMS. No big deal in doing 
> the integration, just plugged in a new BRMSEngine fixture instead of the 
> existing Engine fixture.
> 
> Two questions
> a) This code is generic - would you be interested in a copy for the Fit 
> for Rules project? There are other (minor) updates to the code.
> or
> b) Do you have something big up your sleeve that will (soon) make this 
> redundant (i.e. the QA Tab on the BRMS). Trouble is , would like to 
> write this up now(!). Am I right in assuming the 'QA' tab will 
> effectively be Fit for Rules integrated into the BRMS? (in which case 
> the samples will be easy to port later).
> 
> Ta
> 
> Paul
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
> 
> 

--

-- 
View this message in context: http://www.nabble.com/BRMS-and-Fit-for-Rules-tp15334736p16442903.html
Sent from the drools - dev mailing list archive at Nabble.com.

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
    Permalink | Reply | 501 comments |
    headers
    Hanumesh Mekala (JIRA | 4 Apr 09:41

    [jira] Created: (DROOLS-492) Unable to fire rules - Using drools 4.0.3

    Unable to fire rules - Using drools 4.0.3
-----------------------------------------

                 Key: DROOLS-492
                 URL: http://jira.codehaus.org/browse/DROOLS-492
             Project: drools-legacy
          Issue Type: Test
          Components: fact
         Environment: Windows XP, java1.5,drools 4.0.3
            Reporter: Hanumesh Mekala
            Assignee: bob mcwhirter
         Attachments: testFiles.zip

--

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
    Permalink | Reply | 0 comments |
    headers
    Paul Browne | 4 Apr 10:11
    Favicon
    Gravatar

    Re: [rules-dev] BRMS and Fit for Rules

    Joel,

    As far as I know the the 'integrated testing tool' is available in the latest version of the Drools BRMS (where the screenshots in the blogpost come from). The 'as far as I know' comes from the fact that I'm writing about it, not developing it!

    It's probably worth getting the latest stable build of the BRMS as the features are evolving pretty rapidly with a good feature set already there.

    In the (surprising) case of there not being enough features, Integrating the BRMS (a tool for business types) and Fit / Fitnesse is trivial (can give you the code sample) and easy enough for the Analysts to use.

    Paul

    www.Firstpartners.net/blog

    JoelA wrote:
    Is there anything more to add on this? We are in the same situation as Paul and are considering elaborating fit-for-rules or writing our own fit/fitnesse stuff (maybe more like Servicefixture). We hope to have business types take care of testing their rules based on pkgs dev provides them. I've also read this post: http://blog.athico.com/2007/12/testing-rules-introduction.html What's the status on this 'integrated testing tool' mentioned in the blog? Joel Paul Browne wrote:
    As part of the some 'stuff' (you may be able to guess!) found myself r needing to integrate FIT for Rules and the BRMS. No big deal in doing the integration, just plugged in a new BRMSEngine fixture instead of the existing Engine fixture. Two questions a) This code is generic - would you be interested in a copy for the Fit for Rules project? There are other (minor) updates to the code. or b) Do you have something big up your sleeve that will (soon) make this redundant (i.e. the QA Tab on the BRMS). Trouble is , would like to write this up now(!). Am I right in assuming the 'QA' tab will effectively be Fit for Rules integrated into the BRMS? (in which case the samples will be easy to port later). Ta Paul _______________________________________________ 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
    Permalink | Reply | 501 comments |
    headers
    mmquelo massi | 4 Apr 11:52
    Picon

    [rules-dev] What the.... is happening?

     
    Sorry guys,
     
    but I can't understand why u released 4.0.5 a couple of weeks ago, then u suddenly released
    a brand new "4.0.6" release few days ago (which I promptly downloaded) and now u put back again
    the "4.0.4"....???....
     
    Why???
     
    What is the stable one????
     
    Does the svn is working?? Should we build from repository or shouldn't we?
     
    Looking forward to hearing any news on this matter....
     
    Thank you anyway.
     
    Bye.
     
    Massimiliano
    _______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
    Permalink | Reply | 4 comments |
    headers
    Mark Proctor | 4 Apr 13:10

    Re: [rules-dev] What the.... is happening?

    Yes I'm very sorry about this, we have problems with our QA person - very embarassing. We've rolled back to 4.0.4 and Edson and myself will take care of QA for 4.0.7 which we will release on monday, once I'm recovered from my flu.

    Mark
    mmquelo massi wrote:
     
    Sorry guys,
     
    but I can't understand why u released 4.0.5 a couple of weeks ago, then u suddenly released
    a brand new "4.0.6" release few days ago (which I promptly downloaded) and now u put back again
    the "4.0.4"....???....
     
    Why???
     
    What is the stable one????
     
    Does the svn is working?? Should we build from repository or shouldn't we?
     
    Looking forward to hearing any news on this matter....
     
    Thank you anyway.
     
    Bye.
     
    Massimiliano
    _______________________________________________ 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
    Permalink | Reply | 0 comments |
    headers
    Zoltan Farkas | 4 Apr 18:00

    [rules-dev] Questionable Exception Handling

    I was browsing through the drools source code

     

    I am not a fan of seeing catching Throwable in any java code …

     

    I see this in class org.drools.util.ClassUtils:

     

        /**

         * This method will attempt to create an instance of the specified Class. It uses

         * a syncrhonized HashMap to cache the reflection Class lookup.

         * <at> param className

         * <at> return

         */

        public static Object instantiateObject(String className) {

            Class cls = (Class) ClassUtils.classes.get( className );

            if ( cls == null ) {

                try {

                    cls = Class.forName( className );

                    ClassUtils.classes.put(  className, cls );

                } catch ( Throwable e ) {

                    throw new RuntimeException("Unable to load class '" + className + "'", e );

                }           

            }

           

            Object object = null;

            try {

                object = cls.newInstance();           

            } catch ( Throwable e ) {

                throw new RuntimeException("Unable to instantiate object for class '" + className + "'", e );

            } 

            return object;

        }

     

    I believe this masks important errors where the application should not continue to run and it would be preferable to crash…

     

    --zoly

     

    _______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
    Permalink | Reply | 7 comments |
    headers
    Mark Proctor | 4 Apr 19:55

    Re: [rules-dev] Questionable Exception Handling

    I don't see a problem with Throwable there? We rethrow again, adding in some additional information. I found that just catching Exception didn't work as you could get verification errors and other stuch things. If you look at the context of that that method is doing too, its using reflection to instantiate a class.

    Mark
    Zoltan Farkas wrote:

    I was browsing through the drools source code

     

    I am not a fan of seeing catching Throwable in any java code …

     

    I see this in class org.drools.util.ClassUtils:

     

        /**

         * This method will attempt to create an instance of the specified Class. It uses

         * a syncrhonized HashMap to cache the reflection Class lookup.

         * <at> param className

         * <at> return

         */

        public static Object instantiateObject(String className) {

            Class cls = (Class) ClassUtils.classes.get( className );

            if ( cls == null ) {

                try {

                    cls = Class.forName( className );

                    ClassUtils.classes.put(  className, cls );

                } catch ( Throwable e ) {

                    throw new RuntimeException("Unable to load class '" + className + "'", e );

                }           

            }

           

            Object object = null;

            try {

                object = cls.newInstance();           

            } catch ( Throwable e ) {

                throw new RuntimeException("Unable to instantiate object for class '" + className + "'", e );

            } 

            return object;

        }

     

    I believe this masks important errors where the application should not continue to run and it would be preferable to crash…

     

    --zoly

     

    _______________________________________________ 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
    Permalink | Reply | 6 comments |
    headers
    Geoffrey Wiseman | 4 Apr 20:09
    Picon
    Gravatar

    Re: [rules-dev] Questionable Exception Handling

    In most cases, I'd say that Errors shouldn't even be caught and rethrown, personally -- something like an OOME doesn't need additional object creation, for instance.

    On Fri, Apr 4, 2008 at 1:55 PM, Mark Proctor <mproctor <at> codehaus.org> wrote:
    I don't see a problem with Throwable there? We rethrow again, adding in some additional information. I found that just catching Exception didn't work as you could get verification errors and other stuch things. If you look at the context of that that method is doing too, its using reflection to instantiate a class.

    Mark
    Zoltan Farkas wrote:

    I was browsing through the drools source code

     

    I am not a fan of seeing catching Throwable in any java code …

     

    I see this in class org.drools.util.ClassUtils:

     

        /**

         * This method will attempt to create an instance of the specified Class. It uses

         * a syncrhonized HashMap to cache the reflection Class lookup.

         * <at> param className

         * <at> return

         */

        public static Object instantiateObject(String className) {

            Class cls = (Class) ClassUtils.classes.get( className );

            if ( cls == null ) {

                try {

                    cls = Class.forName( className );

                    ClassUtils.classes.put(  className, cls );

                } catch ( Throwable e ) {

                    throw new RuntimeException("Unable to load class '" + className + "'", e );

                }           

            }

           

            Object object = null;

            try {

                object = cls.newInstance();           

            } catch ( Throwable e ) {

                throw new RuntimeException("Unable to instantiate object for class '" + className + "'", e );

            } 

            return object;

        }

     

    I believe this masks important errors where the application should not continue to run and it would be preferable to crash…

     

    --zoly

     

    _______________________________________________ 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




    --
    Geoffrey Wiseman
    _______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
    Permalink | Reply | 5 comments |
    headers
    Zoltan Farkas | 4 Apr 21:14

    RE: [rules-dev] Questionable Exception Handling

    This is my opinion also and is in line with the java best practices...

Based on javadoc(see class Error and Exception):

"The class Exception and its subclasses are a form of Throwable that indicates conditions that a
reasonable application might want to catch. "

"An Error is a subclass of Throwable that indicates serious problems that a reasonable application should
not try to catch."

In all my apps I want my application to stop on a unrecoverable error (like OOM). However since most
libraries have some catch(Throwable) in the code, I always have to use: 

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${DUMP_PATH} -XX:OnOutOfMemoryError="kill -9 %p"

For me as a user of the drools engine as a 3rd party I would expect that Error not be "hidden" inside a
RuntimeException. For me Errors are something I cannot recover from... however I might choose to
continue the application on a Exception ...

This is my opinion on this...

thanks

--zoly

________________________________________
From: rules-dev-bounces <at> lists.jboss.org [mailto:rules-dev-bounces <at> lists.jboss.org] On Behalf Of
Geoffrey Wiseman
Sent: Friday, April 04, 2008 2:10 PM
To: Rules Dev List
Subject: Re: [rules-dev] Questionable Exception Handling

In most cases, I'd say that Errors shouldn't even be caught and rethrown, personally -- something like an
OOME doesn't need additional object creation, for instance.
On Fri, Apr 4, 2008 at 1:55 PM, Mark Proctor <mproctor <at> codehaus.org> wrote:
I don't see a problem with Throwable there? We rethrow again, adding in some additional information. I
found that just catching Exception didn't work as you could get verification errors and other stuch
things. If you look at the context of that that method is doing too, its using reflection to instantiate a class.

Mark
Zoltan Farkas wrote: 
I was browsing through the drools source code 
 
I am not a fan of seeing catching Throwable in any java code ...
 
I see this in class org.drools.util.ClassUtils:
 
    /**
     * This method will attempt to create an instance of the specified Class. It uses
     * a syncrhonized HashMap to cache the reflection Class lookup.
     * @param className
     * @return
     */
    public static Object instantiateObject(String className) {
        Class cls = (Class) ClassUtils.classes.get( className );
        if ( cls == null ) {
            try {
                cls = Class.forName( className );
                ClassUtils.classes.put(  className, cls );
            } catch ( Throwable e ) {
                throw new RuntimeException("Unable to load class '" + className + "'",
e );
            }            
        }
        
        Object object = null;
        try {
            object = cls.newInstance();            
        } catch ( Throwable e ) {
            throw new RuntimeException("Unable to instantiate object for class '" +
className + "'", e );
        }  
        return object;
    }
 
I believe this masks important errors where the application should not continue to run and it would be
preferable to crash...
 
--zoly
 
________________________________________

_______________________________________________
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

--

-- 
Geoffrey Wiseman

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
    Permalink | Reply | 4 comments |

    Gmane