<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/29/2015 06:22 AM, Max Rydahl
Andersen wrote:<br>
</div>
<blockquote
cite="mid:1AE83DA2-BEA3-481D-82F1-61BAEBA4B4B4@redhat.com"
type="cite"><br>
Then have the management plugin state which version their
libraries are <b class="moz-txt-star"><span class="moz-txt-tag">*</span>from<span
class="moz-txt-tag">*</span></b>, not what version they are
used with.
<br>
<br>
Then the server adapters state which management version they
wish/want/need to use.
<br>
<br>
Then there is no ambiguity and no need to rename the plugins
everytime we need to update.
<br>
</blockquote>
<br>
<br>
Perhaps I'm missing something here. I don't see how your example
prevents me from having to rename plugins. <br>
<br>
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:<br>
<br>
1) Rename the wf8 plugin to wf9, so that its name matches what jars
are inside it<br>
2) Update feature, etc<br>
3) Rename various classes to have wf9 in name instead of wf8<br>
4) Add a new service component with version 9.0.0, with new service
impl class<br>
5) Change existing 8.0.0 service component to delegate to 9.0.0<br>
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. <br>
<br>
<br>
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... <br>
<br>
</body>
</html>