Bug 1009108

Summary: Eclipse plugin uses internal binaries
Product: [Retired] JBoss BRMS Platform 6 Reporter: Tomas Schlosser <tschloss>
Component: Eclipse ToolingAssignee: Kris Verlaenen <kverlaen>
Status: CLOSED NOTABUG QA Contact: Tomas Schlosser <tschloss>
Severity: high Docs Contact:
Priority: medium    
Version: unspecifiedCC: lpetrovi, paradhya, rrajasek
Target Milestone: ---Flags: kverlaen: needinfo+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-09 12:22:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tomas Schlosser 2013-09-17 17:25:28 UTC 
Drools Eclipse plugin uses the Drools binaries packaged inside it (right now it is snapshot from Aug 22). These binaries are used for creating a new Drools Runtime, but also for all the operations within the plugin.

The most problematic of these will be rules compilation. Although the knowledge-api (stored in kie-internal) is used for building legacy projects, deep down in the code it calls the same PackageBuilder as the (new) kie-api.

This may not seem a big problem right now, but in the future it will show. For example if a feature is added to the new version of Drools (say 6.0), but the project uses Drools 5 runtime, it will get runtime problems, that were not identified in Eclipse.
Comment 1 Kris Verlaenen 2013-09-17 19:11:12 UTC 
Tomas,

This is actually all as designed.  Let me try to explain.

(1) The Eclipse plugin is built in the community, we cannot include product jars.  Also, there is just one version of the plugin at all times, used to support different versions of both community and product.

(2) The binaries that are packaged inside could be used for creating a new Drools runtime (if the user selects to do that), but the user can also point the runtime manager to the product version, so they can use the product jars without any issues

(3) It is true that the plugin also uses the internally packaged jars (for features like validation, code completion, etc.), but this is done on purpose:
 - it gives us the ability to implement new features and make them available to older runtimes
 - the jars are only used for so-called supporting features, the actual execution will only rely on the jars selected in the runtime
 - we rely on the fact that the language itself (drl, bpmn2) is backwards compatible, not that the api is backwards compatible

This approach has a disadvantage as well though: during validation or code completion for example, the plugin typically doesn't take the target runtime into account (as we don't really have a way to determine the version and know which features to enable for which version), this could indeed lead to a situation where you might try to use a new feature in combination with an older plugin, in which case validation might not immediately catch this, but you will get the right error when trying to execute your code.  The effort to try and support multiple versions in a 100% accurate way however would be substantial, and there really hasn't been any customer complaining about this yet.  As the user could also just stick to the version of the plugin that was released at the same time as his runtime, in which case he should have a 100% accurate behavior but he will not be able to take advantage of bug fixes or new features.  This approach has been used for several years now, so it seems to withstand the test of time (at least until now).

Does that make sense?
Comment 2 Lukáš Petrovický 2013-10-17 06:05:03 UTC 
qa_ack- in accordance with engineering.