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

[Max Rydahl Andersen]

we talked on chat yesterday, but just to conclude on this thread.

I was simply suggesting that the management.xyz bundles got a consistent 
name related to what they contain OR get some name not related to 
specific version of libs.

from our chat what I got is we ended up with:

* management.xyz bundle names will match what libs they contain. ie. 
management.as7 has jars from as7x, management.wf9 from wildfly 9
* service lookups targets which version to support (not what jars to 
use), so adapters does not have to update their lookups - we just need 
to repackage the management jars.

The rest we would take once PR was done to try/give more direct feedback 
on.

/max

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


/max
http://about.me/maxandersen