[rules-users] Rules storage without Guvnor?

Tue Jun 3 04:28:01 EDT 2014

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 <mproctor at codehaus.org>:

>
> 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
>
>
>
> _______________________________________________
> 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/20140603/deee7220/attachment-0001.html 