[jbosstools-issues] [JBoss JIRA] (JBIDE-17497) Servertools plugin heirarchy has large problem

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 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.