[
https://issues.jboss.org/browse/JBIDE-17497?page=com.atlassian.jira.plugi...
]
Rob Stryker commented on JBIDE-17497:
-------------------------------------
After reviewing the chart, it seems the biggest problem is the plugin
org.jboss.ide.eclipse.archives.webtools. This is the plugin that integrates project
archives with ASTools. This plugin needs to be split into a core and a UI, and it needs to
move further down the stack to below as.core / as.ui.
If this can be done, it'd present a very logical place to put all archives integration
code, one which webservices / esb / bpel would not need to use, but which as.core or
fuseide could depend on.
I previously thought as.runtimes.integration was above as.core, but it seems it must have
been moved down, and so this is no longer an issue. Any runtime integration code can live
there without dragging in as.core. This is a good thing.
Servertools plugin heirarchy has large problem
----------------------------------------------
Key: JBIDE-17497
URL:
https://issues.jboss.org/browse/JBIDE-17497
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: server
Affects Versions: 4.2.0.Beta2
Reporter: Rob Stryker
Priority: Critical
Attachments: 2014-06-02 19.07.bmml, 2014-06-02 19.07.png
The plugin heirarchy of ASTools is better than it used to be, but not good enough for
what current consumers of ASTools need it for.
The problem is simple. There are 3 types of clients using ASTools API:
1) Those who need all of ASTools installed (including server adapter)
2) Those who only want access to interfaces, to use *if* server adapters is installed
(do NOT want as.core force installed)
3) Those who create their own server adapters, want to use interfaces and some impl
classes, but do not want as.core (server adapters) installed.
Those of group 1 are no problem.
Those of group 2 want as.wtp.core and as.wtp.ui to be minimal implementations with very
few (near-zero) dependencies
Those of group 3 want as.wtp.core and as.wtp.ui to provide as much functionality as
possible, including things like zipping archives, or integration with download runtimes.
An example of group 1 is jbosstools-central.
An example of group 2 is ESB / BPEL
An example of group 3 is FuseIDE
Currently, there are classes in plugins positioned above as.core (ie, depend on as.core)
that would be useful to FuseIDE (integration with stacks / runtimes / archives), but
pushing these classes down into as.wtp.core / as.wtp.ui would mean the as.wtp.* plugins
now require archives / stacks / yaml, and then so does bpel / esb.
There needs to be another set of core/ui plugins for extenders or implementers that do
NOT bring in the server adapters.
Alternatively, we could move the server adapters out of as.core / as.ui and into two new
higher-level plugins, as.serveradapter.core / as.serveradapter.ui, leaving as.core/as.ui
as the new plugins to be extended by fuse-ide.
There are of course other possible solutions, but all possible solutions basically
require new plugins with substantial class movement.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)