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