headers
bob mcwhirter | 1 Jul 2004 17:47

[drools-dev] IDE files


I use XEmacs.  I don't know diddly about the IntelliJ or Eclipse build
files.

If we *can* make a set that works universally, across platforms and
JDK versions, I'm all for having them in CVS.  Then folks can sync and
build w/o maven.  But really, that's not much of a concern, since Real
Developers Use Maven.

If they support a single platform or JDK, then they probably don't
belong in CVS.

But, as noted, I don't know diddly.

So, guys, please, figure out if they are universally useful, if so, keep'em,
if not, figure out if they can be made universally useful, or nuke'em.

But figure it out amongst yourselves, please.

	-bob
Permalink | Reply | 0 comments |
headers
Doug Bryant | 2 Jul 2004 14:02

[drools-dev] groovy drl example

I started creating groovy drl files based off of all the existing
example java drl files.

The only problem I see now is that we probably don't want to have
duplicate example java classes that use the drl files.

I would propose changing the examples around a little so that the main
method in the example  java classes can be passed an argument and told
which drl file to use.  We could then have a maven target that passed in
the correct drl file to use.  For example, the target:

maven familytree

would then become 
maven familytree-java and 
maven familytree-groovy, etc.

each familytree-java or familytree-groovy would pass the correct drl
file as an argument to main.

The only question would then become how to repackage the examples.

Could go with either (hope formatting in email comes out ok)

                              .java
org.drools.examples.familytree
                              .groovy

where the java classes would reside in the familytree package and the
drl files would reside in the java/groovy package underneath familytree.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andy Barnett | 2 Jul 2004 16:13

Re: [drools-dev] groovy drl example

I agree duplicate example java classes shouldn't reside in multiple 
places in CVS.

Why not simply create an org/drools/examples/familytree directory with 
the shared java classes, and right along side them familytree.java.drl 
and familytree.groovy.drl files? It seems excessive to me have extra 
directories that contain just a single DRL file each.

Also, I believe if you use the Class.getResource() method to load the 
DRL files, you won't need to specify anything more than their filenames 
if they reside in the same directory/java-package as the example class. 
  Like so:

public static void main( String[] args ) throws Exception {
     String drlFilename = args[0]; // familytree.java.drl or 
familytree.groovy.drl
     URL url = FamilyTree.class.getResource( drlFilename );
     [ . . . ]
}

~Andy

On Jul 02, 2004, at 7:02 AM, Doug Bryant wrote:

> The only question would then become how to repackage the examples.
>
> Could go with either (hope formatting in email comes out ok)
>
>
>                               .java
(Continue reading)

Permalink | Reply | 3 comments |
headers
N. Alex Rupp | 2 Jul 2004 18:38

[drools-dev] OOC, why keep bsh and antlr in cvs?

Why do we currently have bsh & antlr in cvs?  Was this decided before 
they were available from ibiblio or something?
--
Alex
Permalink | Reply | 1 comment |
headers
Doug Bryant | 2 Jul 2004 13:19
Gravatar

[drools-dev] groovy drl examples

I started creating groovy drl files based off of all the existing
example java drl files.

The only problem I see now is that we probably don't want to have
duplicate example java classes that use the drl files.

I would propose changing the examples around a little so that the main
method in the example  java classes can be passed an argument and told
which drl file to use.  We could then have a maven target that passed in
the correct drl file to use.  For example, the target:

maven familytree

would then become 
maven familytree-java and 
maven familytree-groovy, etc.

each familytree-java or familytree-groovy would pass the correct drl
file as an argument to main.

The only question would then become how to repackage the examples.

Could go with either (hope formatting in email comes out ok)

                              .java
org.drools.examples.familytree
                              .groovy

where the java classes would reside in the familytree package and the
drl files would reside in the java/groovy package underneath familytree.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Barnett | 2 Jul 2004 16:49

Re: [drools-dev] OOC, why keep bsh and antlr in cvs?

I believe at the present time only the JCA and JSR-94 JAR files 
(jca-1.0.jar & jsr94-1.0.jar) are not hosted at ibiblio.  You should be 
able to safely remove the beanShell and ANTLR JAR files.  Additionally, 
littered about the various drools-*/*lib directories are more 
unnecessary JARs for commons-logging, groovy, JAAS, and Jython.  I 
believe in all cases either the files can be found hosted at ibiblio or 
are not required at all by the currect Drools code.

Cheers,
~Andy

On Jul 02, 2004, at 11:38 AM, N. Alex Rupp wrote:

> Why do we currently have bsh & antlr in cvs?  Was this decided before 
> they were available from ibiblio or something?
> --
> Alex
>
Permalink | Reply | 0 comments |
headers
list | 2 Jul 2004 16:28

Re: [drools-dev] groovy drl example

good idea just leaving out the java/groovy sub directories and calling the
files familytree.groovy.drl, etc.

Thats precisely how I was thinking I would load the drl files ;)

Doug

> I agree duplicate example java classes shouldn't reside in multiple
> places in CVS.
>
> Why not simply create an org/drools/examples/familytree directory with
> the shared java classes, and right along side them familytree.java.drl
> and familytree.groovy.drl files? It seems excessive to me have extra
> directories that contain just a single DRL file each.
>
> Also, I believe if you use the Class.getResource() method to load the
> DRL files, you won't need to specify anything more than their filenames
> if they reside in the same directory/java-package as the example class.
>   Like so:
>
> public static void main( String[] args ) throws Exception {
>      String drlFilename = args[0]; // familytree.java.drl or
> familytree.groovy.drl
>      URL url = FamilyTree.class.getResource( drlFilename );
>      [ . . . ]
> }
>
> ~Andy
>
> On Jul 02, 2004, at 7:02 AM, Doug Bryant wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Doug Bryant | 3 Jul 2004 15:27

[drools-dev] Patch for examples - groovy example for every java example

I attached a zip file to Drools issue DROOLS-90.  Contains a patch for
drools-examples using goovy.  See message I attached to issue for more
detail.

I'll start doing some documenting on the groovy semantic module  after
the long weekend.

Let me know if there are any problems or issues.

Doug
Permalink | Reply | 0 comments |
headers
Mark Proctor | 4 Jul 2004 18:20

[drools-dev] Serialisation and Rete*

I have completed the serialisation work (DROOLS-86) I have added unit 
tests and also examples for fibonacci. We now need simple-jndi added as 
a dependency, can someone please add the following to ibiblio:
http://www.markproctor.com/simple-jndi-0.9.jar

The examples are started with maven fibonacciJNDI and fibonacciSerliazed

For those who want to look at something interesting I found an article 
on a Rete algorithm optimised with Treat - didn't realise that Games 
companies were researching this type of stuff (Drools-114) 
http://www.cs.bris.ac.uk/Publications/Papers/2000091.pdf

Mark
Permalink | Reply | 0 comments |
headers
Mark Proctor | 4 Jul 2004 18:23
Picon

[drools-dev] Dumper

Its now possible to dump the Rete network with org.drools.reteoo.Dumper
Dumper dumper = new Dumper(ruleBase);
dumper.dumpRete(System.out);

This work is on going, so please feel to add/correct.

Mark
Permalink | Reply | 0 comments |

Gmane