[rules-users] Drools 6 support for changeset

[Mark Proctor]

On 13 Dec 2013, at 13:51, lbilger <lars.bilger at lhsystems.com> wrote:

> I thought that was what the KieScanner did?
KieScanner re-resolves the pom and it’s dependencies, and checks against what is currently deployed. If any of the versions have changed, it updates the current KieContainer.


> I spent some time trying to get
> it to work as I would expect it to, but ran into several problems that made
> me go back to 5.5 for now.
> 
> Here's what I did:
> I created two maven projects, one to contain the rules ("drools6:rules") and
> one to use them ("drools6:drools6").
> In "drools6:drools6" I created a Main class and method in which I initialize
> the KieContainer and KieScanner as follows:
> 
>        KieServices kieServices = KieServices.Factory.get();
>        ReleaseId releaseId = kieServices.newReleaseId("drools6", "rules",
> "1.0.0-SNAPSHOT");
>        final KieContainer kieContainer =
> kieServices.newKieContainer(releaseId);
>        KieScanner kieScanner = kieServices.newKieScanner(kieContainer);
>        kieScanner.start(1000);
>        // Some code to see when rules were changed
>        System.in.read(); // Keep the VM running while waiting for rule
> changes
> 
> Now I would expect the rules to be automatically picked up if I change them
> in "drools6:rules" and "mvn install" it. But no changes are detected.
There is a limitation in 6.0.0 - fixed in master. Once you pass in the initial root releaseId - it resolves it to real version, and uses that for all scanNows. So only dependencies in the pom.xml will have their -SNAPSHOT re-resolved. The work around was to create a wrapper project.

A previous email "Re: [rules-users] Drools 6 and dynamic update”:
"On a side note, on master, there is a change to ensure that the Maven syntax for scanNow (with using the KieScanner) is obeyed. see
https://issues.jboss.org/browse/DROOLS-356"


> I
> debugged the KieScanner and it seems that it compares the version number of
> the releaseId to the one from the repository, which is "1.0.0-SNAPSHOT" in
> both cases, so the new jar is not considered newer.
> 
> So I thought, "OK, so I need to change the version number". I changed the
> version of the "drools6:rules" project to 1.0.1-SNAPSHOT. This didn't help
> either, because the releaseId explicitly requests 1.0.0-SNAPSHOT, so the
> newer version is never loaded.
> 
> My next idea was to use "LATEST" in the releaseId instead of an explicit
> version. At first this did not work for my local repository, but after
> manually editing the maven metadata file and adding a <latest> tag, it found
> the new version. But now, the KieScanner found a change every time it looked
> because it compared the version string "LATEST" to "1.0.1-SNAPSHOT" and
> always considered the "real" version newer. With a certain amount of rules
> and a short polling interval this caused the KieContainer to be busy
> rebuilding all the time and a very high CPU load.
> 
> I also tried deploying to a real maven repository instead of just installing
> to local, but with no success.
> 
> 
> What am I missing here? Or isn't this how the KieScanner is supposed to
> work?
Try the latest snapshot, that has the above issue, in 356,  fixed.
http://downloads.jboss.org/drools/release/snapshot/6.0.x/
> 
> Thanks
> Lars
> 
> 
> Mark Proctor wrote
>> We do not have any file change listeners. You, or the workbench, needs to
>> build the jar.
>> 
>> What is automatic is the role of change sets before. You no longer need to
>> compute them, build the jar, have the client consume the jar  (with
>> different ReleaseID) - that’s it. Drools diffs the current and target jar,
>> and upgrades accordingly.
>> 
>> Mark
> 
> 
> 
> 
> 
> --
> View this message in context: http://drools.46999.n3.nabble.com/Drools-6-support-for-changeset-tp4027138p4027279.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> 
> _______________________________________________
> 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/20131213/5d0a52c9/attachment-0001.html