[
https://jira.jboss.org/jira/browse/JBIDE-2752?page=com.atlassian.jira.plu...
]
Max Rydahl Andersen updated JBIDE-2752:
---------------------------------------
Fix Version/s: 3.0.0.cr1
(was: 3.0.0.beta1)
Priority: Blocker (was: Major)
slip out of beta1.
Upgraded to blocker for cr1 since we need this to bundle-use it with Drools 4
runtimes...
Make Drools plugin aware of external runtimes
---------------------------------------------
Key: JBIDE-2752
URL:
https://jira.jboss.org/jira/browse/JBIDE-2752
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: drools
Affects Versions: 3.0.0.alpha
Reporter: Max Rydahl Andersen
Assignee: Kris Verlaenen
Priority: Blocker
Fix For: 3.0.0.cr1
The current Drools plugin has only one notion of runtime: the one used internally in the
drools plugin it self.
This has several usability issues:
1) In a team project it will not necessarily be the same jars developers will be using if
they have different versions of the plugin installed
2) It is a problem if you have projects with different versions of Drools - there are
only one "allowed" in the eyes of the drools plugin
3) the classpath container added will expose .org jars which is bad if the user is meant
to use the EAP/SOA-P certified jars
If Drools is going into JBDS 2/JBossTools 3 we need to change this so we don't force
users to live on the bleeding edge.
My suggestion is:
1) No longer *ever* expose the internal drools.jars to users projects
2) Add the notion of Drools runtimes which has version and list of jars defined similar
to Java Runtimes in Eclipse JDT.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira