http://permalink.gmane.org/gmane.comp.java.drools.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.java.drools.devel/2759 _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Michal Bali 2008-12-03T21:48:35 http://permalink.gmane.org/gmane.comp.java.drools.devel/2758 No that won't help as it still is the same classname from the IDE content assistance point of view. No quick fix I can see, the only 3 options are to tweak the IDE to ignore the "old" or internal ones, or use differnt classnames for the new ones ;) - probably not practical. Sent from my iPhone On 29/11/2008, at 7:38, Mark Proctor <mproctor< at >codehaus.org> wrote: _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Michael Neale 2008-11-30T07:04:30 http://permalink.gmane.org/gmane.comp.java.drools.devel/2757 _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Michael Neale 2008-11-30T07:02:00 http://permalink.gmane.org/gmane.comp.java.drools.devel/2756 one option is to put drools api under a totaly new namespace - org.drools5 instead of org.drools. But I'm not keen to do this, although I know hibernate did it moving to hibernate 3. I'm trying to get a CR out in a week or so, so what ever we decide, we are rapidly running out of time. Mark Mark Proctor wrote: _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Mark Proctor 2008-11-28T20:38:43 http://permalink.gmane.org/gmane.comp.java.drools.devel/2755 _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Mark Proctor 2008-11-28T14:57:36 http://permalink.gmane.org/gmane.comp.java.drools.devel/2754 _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Ashish Redkar 2008-11-28T13:29:36 http://permalink.gmane.org/gmane.comp.java.drools.devel/2753 Compioitions now work and the new Resource framework is committed. You can see the api in action here: http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-decisiontables/src/test/java/org/drools/decisiontable/CompositionTest.java Along with the xml knowledge composition file it is loading: http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-decisiontables/src/test/resources/org/drools/decisiontable/composition1Test.xml The summarised version is: <composition xmlns='http://drools.org/drools-4.0/composition' xmlns:xs='http://www.w3.org/2001/XMLSchema-instance' xs:schemaLocation='http://drools.org/drools-4.0/composition drools-composition-4.0.xsd' > <resource source='classpath:org/drools/decisiontable/composition1Test.drl' type='DRL' /> <resource source='classpath:data/IntegrationExampleTest.xls' type="DTABLE"> <decisiontable-conf input-type="XLS" worksheet-name="Tables_2" /> </resource> <resource source='classpath:org/drools/decisiontable/compo Mark Proctor 2008-11-28T07:10:12 http://permalink.gmane.org/gmane.comp.java.drools.devel/2752 _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Mark Proctor 2008-11-27T13:12:42 http://permalink.gmane.org/gmane.comp.java.drools.devel/2751 Hi, What might be possible in 5.1? Ability to plug-in custom Resource implementation or a resource implementation that will look into repository. I hope the former is available in 5.0 :-). I understood the resource configuration part. Would it make sense to have Knowledge Builder configuration on lines of resource being part and Knowledge Builder being whole? Typically for executing any business functionality we have more than one resources involved. This may happen due to splitting of rules based on different sub features but wanting to execute the top level feature (basically easy maintainability). Or it could be pure dynamism needed during execution. With this typical usage in mind I feel that having a Knowledge Builder level configuration may help in maintenance of executable rules. Regards, - Nimesh -----Original Message----- From: rules-dev-bounces< at >lists.jboss.org [mailto:rules-dev-bounces< at >lists.jboss.org] On Behalf Of Mark Proctor Sent: Thursday, November 27, 2008 2:05 PM To: Rules Dev List Sub Nimesh Muley 2008-11-27T09:47:18 http://permalink.gmane.org/gmane.comp.java.drools.devel/2750 This might be possible, I'll bear it in mind as an enhancements for 5.1. If you look at the javadocs for drools-api ResourceConfiguration is specific to what you are loading, for instance with decision tables (the only place where it is currently used) it provides the binary type, XLS or CSV, and optionally the worksheet name. Mark is e-mail in error, kindly delete this e-mail from desktop and server. _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Mark Proctor 2008-11-27T08:34:53 http://permalink.gmane.org/gmane.comp.java.drools.devel/2749 Hi, To load a resource from DB would someone need to provide a custom implementation of Resource (meant for DB lookup) and then use it in the KnowledgeBuilder? Can this definition be later extended to load a resource from a repository once repository concept is there during execution time (similar / same as what is available at definition time)? Should resource configuration at Resource level (part) or at KnowledgeBuilder? As per my understanding of the definition below, it seems more apt at KnowledgeBuilder level. Regards, - Nimesh -----Original Message----- From: rules-dev-bounces< at >lists.jboss.org [mailto:rules-dev-bounces< at >lists.jboss.org] On Behalf Of Mark Proctor Sent: Thursday, November 27, 2008 12:01 PM To: Rules Dev List Subject: [rules-dev] Knowledge Composition and Parts I'm in the process of doing the final changes to drools-api. Having done the spring work, not yet committed, I liked their resource framework, so decided to copy this for Drools. So we now have: KnowledgeBuilder.add( Resource, Nimesh Muley 2008-11-27T07:23:31 http://permalink.gmane.org/gmane.comp.java.drools.devel/2748 I'm in the process of doing the final changes to drools-api. Having done the spring work, not yet committed, I liked their resource framework, so decided to copy this for Drools. So we now have: KnowledgeBuilder.add( Resource, KnowledgeType, ResourceConfiguration ); Where we support the following Resource sources: FileSystemResource, ClassPathResource, UrlResource ByteArrayResource, ReaderResource, EncodedResource and InputStreamResource In use it'll look like: kbuilder.add( ResourceFactory.newClassPathResource( "somefile.drl", classLoader ), KnowledgeType.DRL ) I do not yet do knowledge type inference from the .ext - I think I'll leave that till after 5.0, if I do it at all. So kbuilder.addResource( URL, ...) and kbuilder.addResource( Reader, ... ) from M3 no longer exist and are as above. What I'm adding now is the ability to provide an xml file that is a configuration of resources to load. The term Configuration is overloaded, and we use this more to provide the directives for knowledgebuild Mark Proctor 2008-11-27T06:30:52 http://permalink.gmane.org/gmane.comp.java.drools.devel/2747 _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Michal Bali 2008-11-26T01:10:57 http://permalink.gmane.org/gmane.comp.java.drools.devel/2746 _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Mark Proctor 2008-11-25T16:02:01 http://permalink.gmane.org/gmane.comp.java.drools.devel/2745 _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Michal Bali 2008-11-25T11:51:06 http://permalink.gmane.org/gmane.comp.java.drools.devel/2744 _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Mark Proctor 2008-11-25T06:07:09 http://permalink.gmane.org/gmane.comp.java.drools.devel/2743 Documentation and Javadocs are now published continiously (we'll about 1 hour apar) as they change, as part of the hudson build server. https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/index.html https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/javadocs/index.html So now people should be able to review our doc changes as they happen. Mark _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Mark Proctor 2008-11-25T04:08:30 http://permalink.gmane.org/gmane.comp.java.drools.devel/2742 _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Mark Proctor 2008-11-24T05:42:23 http://permalink.gmane.org/gmane.comp.java.drools.devel/2741 Well, if you look at String.getBytes() it uses the default encoding, then ISO-8859-1 if that fails. (Default is UTF-8 unless otherwise specified in the "file.encoding" property.) As long as that's documented I guess it's not a problem, unless someone wants to specify their own charset for a particular file. Java 1.6 has String.getBytes(Charset) and that could allow someone to use an alternate charset. I figure for the vast majority of cases it won't be a problem. --- On Sun, 11/23/08, Mark Proctor <mproctor< at >codehaus.org> wrote: _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Greg Barton 2008-11-24T05:13:39 http://permalink.gmane.org/gmane.comp.java.drools.devel/2740 I'm thinking of adopting the Spring approach to Resources for drools-api, obviously not tieing drools-api to spring - just copying the concept. Resource however doesn't seem to work with Readers. Readers in general are only needed for in memory generation , using StringReader, otherwise file/url/classpath resources suffice. So it seems to do the Spring way you would do a ByteArrayResource( "this is my drl file".getBytes() ). I'm wondering what people think of that, and what about encoding issues? Compared to the way at the moment that we just take a Reader, and that's it. Mark Mark Proctor wrote: _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Mark Proctor 2008-11-24T03:09:08 http://permalink.gmane.org/gmane.comp.java.drools.devel/2739 now my spring skills are improving, I'm looking to improve the xml and leverage spring Resource framework - so that we can get complete scripting of the entire KnowlegeBuilder api. I've come up with the two xmls so far: <property name="drls"> <list> <value>file:src/main/java/org/drools/ioc/spring/testSpring.drl</value> </list> </property> <property name="dtables"> <list> <bean class="org.drools.ioc.spring.DtableResourceFactoryBean"> <property name="resource" value="file:src/main/java/org/drools/ioc/spring/dt.xls" /> <property name="inputType" value="XLS" /> </bean> </list> </property> This one has a property per knowledge type, the advantage is on knowledge types which are just string, we can use a simple <value>. Although knowlege tyep that require additional information, like the D Mark Proctor 2008-11-24T02:17:29 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.drools.devel