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

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972334#comment-12972334 ] 

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)