> Does the API allow decoupling ? (i.e. one option is the plugin
> load dynamically the runtime jars from the targeted runtime)
See my previous response. The real problem is the stability of those APIs. No amount of
decoupling allows you to instantly see new features or retract removed features, unless
you're putting together a dynamic GUI, which is then limited in its usability (e.g.
generic JMX consoles, generic WS testers, etc.; they get the job done, they adapt nicely,
but they aren't very pretty).
I've never expected to magically see new features pop up in tools ;)
I do though expect tools to support multiple versions of runtimes and preferably not break
completely in the instance that a new version is out of runtime....and yes this assumes
the runtimes doesnt change their "api"'s radically (i.e. our AS tooling
built for starting/stopping AS 3.x continued to "just work" all the way up to AS
5 for most things and more or less gracefully handled differences) . But of course too big
changes sometimes do happen and a new release of the plugin needs releasing to support
them - i.e. AS 5->6 and especially AS 6->7 had changes that prevented launch.
My point is just that the plugin should at least handled multiple versions - and then its
more or less up to the runtimes to decide how much change they do or not do to ensure
tooling doesn't break on every new release.