Re: [jbosstools-dev] Question on all external users of IJBoss7ManagerService
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