[jbosstools-issues] [JBoss JIRA] Resolved: (JBIDE-2752) Make Drools plugin aware of external runtimes

[Kris Verlaenen (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBIDE-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen resolved JBIDE-2752.
-----------------------------------

    Resolution: Done


The necessary improvements have been made to the Drools Eclipse plugin to support multiple runtimes, including:
 - Drools classpath container now uses jars from a runtime on the file system instead of from jars inside the plugin
 - Drools runtimes preference page to configure runtimes (or create a new one from the jars inside the plugin)
 - Drools project preference page to select a project-specific runtime if necessary

[Corresponds to JBRULES-1833, the latest enhancements were committed under revision 24221 in the Drools svn repository.]

> 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