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.Final/org/kie/scanner/embedder/MavenSettings.java/?v=source 2014-06-02 21:55 GMT+02:00 Mark Proctor <mproc...@codehaus.org>: > > On 2 Jun 2014, at 16:21, Horváth Péter Gergely <h.pe...@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 <mproc...@codehaus.org>: > >> >> On 2 Jun 2014, at 08:40, Péter Gergely, Horváth <h.pe...@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> _______________________________________________ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users >
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users