[jbosstools-dev] Question on all external users of IJBoss7ManagerService

Rob Stryker rstryker at redhat.com
Mon Jun 29 15:46:43 EDT 2015


On 06/29/2015 06:22 AM, Max Rydahl Andersen wrote:
>
> Then have the management plugin state which version their libraries 
> are *from*, not what version they are used with.
>
> Then the server adapters state which management version they 
> wish/want/need to use.
>
> Then there is no ambiguity and no need to rename the plugins everytime 
> we need to update.


Perhaps I'm missing something here. I don't see how your example 
prevents me from having to rename plugins.

If, for example, I have a plugin with jars from wf8, and the plugin is 
named wf8.management,   and then we decide to upgrade to wf9 jars, I 
don't see how your solution fixes anything?  It seems my migration path 
is to then:

1) Rename the wf8 plugin to wf9, so that its name matches what jars are 
inside it
2) Update feature, etc
3) Rename various classes to have wf9 in  name instead of wf8
4) Add a new service component with version 9.0.0, with new service impl 
class
5) Change existing 8.0.0 service component to delegate to 9.0.0
6) Add new version constant to IJBoss7ManagerService list of constants, 
to ensure that any downstream adopter (teiid fuse etc) depending on 
specific service versions (which they shouldn't do, but still might) are 
not broken by a removed constant or a removed service corresponding to 
that constant.


Or are you suggesting that I keep the wf8.management plugin with its 
constants and jars and then add a new wf9.management plugin with new 
constants / services / jars?  Clearly then we'd experience a ballooning 
of client jars...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150629/56ace75e/attachment.html 


More information about the jbosstools-dev mailing list