[rules-users] Rules storage without Guvnor?

Mark Proctor mproctor at codehaus.org
Mon Jun 2 15:55:08 EDT 2014


On 2 Jun 2014, at 16:21, Horváth Péter Gergely <h.peter at mailbox.hu> wrote:

> Hi Mark,
> 
> Thank you for your help. Creating a custom build of Guvnor sounds to require quite some effort, I'm not sure whether we should go down that way. 
> 
> Unfortunately, I don't think we will have the option to use Maven based rule deployments at all. In Drools 6, KieScanner seems to be built around Maven; this doesn't suit environments where the application runs on servers without Maven (e.g. no Maven installed, no local Maven repository allowed, access to remote Maven repositories blocked by firewall.) 
> 
maven is just a JAR like any other JAR. And a Maven repo is just a file system. If you write something or use something else, it’s just going to be creating equivalents.
> Do you see any way for us to load rule files directly from the file system and still have the automatic change detection?
Use the maven plugin. You don’t need to be  maven enterprise to use maven.
> For example, we could push rule files to NFS with CI and let the application detect and pick up changes... 
> 
> Thanks,
> Peter
> 
> 
> 
> 2014-06-02 14:13 GMT+02:00 Mark Proctor <mproctor at codehaus.org>:
> 
> On 2 Jun 2014, at 08:40, Péter Gergely, Horváth <h.peter at mailbox.hu> wrote:
> 
>> Hello All,
>> 
>> We are evaluating Drools for our use case and would have a question for storing rules files. We are in a relatively constrained environment, where getting Guvnor up and running does not seems to be a valid option. Since we would only need the core repository functionality so that we can separate rule deployment from application deployments (and none of the advanced features like online editing etc), I think it would make more sense to have a light-weight alternative for storing the rule files.
> In 6.0 our rules are stored in GIT, it doesn’t get much lighter than that
> 
> Our UI is easily customisable if you know how, as it’s all modular, and everything is a plugin. So you can hide/disable the parts that you do not want available at run time, although at the moment that requires a rebuild.
> 
>> 
>> Being able to pick up rules from an NFS share of from a database CLOB field would be perfectly sufficient for us. I have worked with JBPM4 quite a lot, where the core engine contained support for versioned storage of the process definitions in the database itself [1]. 
> I don’t see how this would be better than GIT, and certainly a lot more complicated and heavier.
> 
>> 
>> Is there any similar feature in Drools, where the rules can be deployed to e.g. a database or any other repository solution, (without using Guvnor)?
> No, I don’t see what value this would have (simply storing a clob). I could potentially see value in an indexed/exploded rules stored in a DB for refactoring, x-reference, analysis work. But this would be additional to the GIT storage, and not instead of.
> 
>> I haven't found too much details on this topic, but for me it seems that the only approach would be to have some custom logic, which programmatically checks for rule updates and re-creates the whole knowledgebase on any update.
> You can use our Maven plugin for this with GIT. You can poll or add a GIT hook. You can look into hudson for automating this.  JGIT doesn’t expose hooks right now, so you’d need to use your own GIT (which wouldn’t work with guvnor, although you can GIT-Mirror the two).
>> I am wondering whether there is any more sophisticated solution in Drools where at least update checking/rule reconfiguration could be delegated to the engine. 
> The best way would be to extend the maven plugin to provide this functionality, but make sure it’s independent of maven too. If you do this right, we can look at integrating it into the main Guvnor codebase.
> 
> Mark
>> 
>> Any inputs are appreciated. 
>> 
>> Thanks,
>> Peter
>> 
>> [1] http://docs.jboss.com/jbpm/v4/javadocs/org/jbpm/api/RepositoryService.html     
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
> 
> 
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
> 
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140602/c1743ee3/attachment.html 


More information about the rules-users mailing list