It is currently possible to create a KieContainer with a ranged version instead of a fixed one, but this range is not used by the KieScanner that instead consider only the fixed version of the first fetched project.
Mario Fusco <mario.fusco> updated the status of jira DROOLS-356 to Resolved
Fixed by https://github.com/droolsjbpm/drools/commit/ba79df043
Some background for this. When a KieModule is looked up, it allows a version String. The KieModule resolves a jar using Maven. As such engineers expect it to support any standard Maven convention for Strings. But it did not support versions. Further it would lose the original version request; such as -SNAPSHOT. So scanNow would not pick up the latest. The change allows any Maven version string to be passed, as any engineer would expect, and to ensure that original string is used each time scanNow is called.
Mark Proctor <mproctor> made a comment on jira DROOLS-356 Some background for this. When a KieModule is looked up, it allows a version String. The KieModule resolves a jar using Maven. As such engineers expect it to support any standard Maven convention for Strings. But it did not support versions. Further it would lose the original version request; such as -SNAPSHOT. So scanNow would not pick up the latest. The change allows any Maven version string to be passed, as any engineer would expect, and to ensure that original string is used each time scanNow is called. The current work around is to create an empty wrapper project, to control deployment updates. This project's pom would be resolved by maven, and thus all version syntax is supported and corrected resolved.
Verified in BRMS 6.0.1-redhat-2