What version are you considering (the reply differs for each). Sent on the move On 2 Jun 2014 08:40, "Péter Gergely, Horváth" <h.peter(a)mailbox.hu&gt; wrote:

On 2 Jun 2014, at 08:40, Péter Gergely, Horváth <h.peter(a)mailbox.hu&gt; wrote: 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. I don’t see how this would be better than GIT, and certainly a lot more complicated and heavier. 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. 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). 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

Hi Guvnor implements a REST API that can be used to get a big DRL from ressources in a package. Most of time in my company's projects we used this API to get and store DRL files in a production environnement, with some dedicated code (no maven nor web in prod). It is almost as simple as copying files, the REST api is simple to use and works great, with all versions (did not test the 6.0, but I use almost the same code since guvnor 5.2). Guvnor only exists in the "authoring environnement", and rules should be tested before being deployed (via DRL file copying on a NFS, but a BLOB would work too) in the real prod env, which has no Guvnor at all. We have specifc code to load rules into a new session and execute it on our data (loading new rules if he file has changed). This last point does not use latest drools spring integration (with agents etc etc) mainly because I had to do that kind of thing a long time ago when all that stuff did not exist and from there I go on with some code that I can easily change. But it is quite easy to do (not immediate neither) and you won't depend on some drools code that may change over versions if you want to inject some of your tricks in the middle of the process. In my opinion, Guvnor should be used if you need to make your business user to author rules by themselves. As far I understood from your other posts, you have a lot of old java code to port to new java/rules code, but nowhere you mention who will maintain this. If is it only dev guys, you certainly don't need gunvnor at all and deal directly with your favorite IDE and Git with normal source files (DRL, DSRL, XLS, or whatever, there are numbers of code samples in the doc that tells you how to feed a KB with file ressources). ----- Mail original ----- De: "Horváth Péter Gergely" <h.peter(a)mailbox.hu&gt; À: "Rules Users List" <rules-users(a)lists.jboss.org&gt; Envoyé: Lundi 2 Juin 2014 17:21:11 Objet: Re: [rules-users] Rules storage without Guvnor? 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.) Do you see any way for us to load rule files directly from the file system and still have the automatic change detection? 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(a)codehaus.org > : On 2 Jun 2014, at 08:40, Péter Gergely, Horváth < h.peter(a)mailbox.hu > wrote: <blockquote> 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. <blockquote> 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]. </blockquote> I don’t see how this would be better than GIT, and certainly a lot more complicated and heavier. <blockquote> 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)? </blockquote> 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. <blockquote> 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. </blockquote> 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). <blockquote> 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. </blockquote> 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 <blockquote> 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users </blockquote> _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users </blockquote> _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Mark, thank you for your input, I really appreciate it. Based on that, my conclusion is the following (please correct me if I am wrong): - we should have a separate Maven project, that contains all of our business rules. - the JAR file built from this project should be installed to a local Maven repository so that KieScanner can pick it up - we can place this local Maven repository to NFS, where it is available for both to our production and build server - the application should be configured to watch the Maven repository on NFS using KieScanner Question is: how should I configure the location of the Maven repository KieScanner scans? Unfortunately none of the supported options for supplying Maven settings would work for us: - The Maven install: $M2_HOME/conf/settings.xml: we do not have Maven installed on production servers - A user's install: ${user.home}/.m2/settings.xml: we do not have access to the server user's environment - Folder location specified by the system propert kie.maven.settings.custom: we do not control the Tomcat servers our application runs on: system properties cannot be changed. Based on what I know, class org.kie.scanner.embedder.MavenSettings [1] is responsible for loading Maven settings. The only way I see to supply a custom location for settings.xml is monkey-patching this class in our project. Do you know any alternative to this? If there is not other solution, I think it would be worth exposing this via the API. What do you think? Peter [1] http://grepcode.com/file_/repo1.maven.org/maven2/org.kie/kie-ci/6.0.1.Fin... 2014-06-02 21:55 GMT+02:00 Mark Proctor <mproctor(a)codehaus.org&gt;: