[jbosstools-dev] ASTools Refactor (as always), advice required from consumers!

[Rob Stryker]

Hi All:

OPENSHIFT, TEIID DESIGNER, CENTRAL, and others....  HEAR ME!

I'm working on drawing out the beginning plans of a somewhat large 
refactor to astools, specifically to server behavior (module start / 
stop, deploy, server start / stop, management commands, etc).

What I need from you all is a comprehensive list of how you're all 
interacting with astools as of now, and what things you'd LIKE to see in 
the future. This will be a major version bump when complete, and while I 
will do my best to not severely break api, I will. I know I will, 
because it's about time thats been done and the old cruft gets cleaned.

Obviously existing servers will continue to function. That would be a 
critical breakage and even I won't do that, but, I would like to make 
all consumers of astools' migrations as easy as possible.

Even though most of these changes will be to classes that should have 
been internal but never were, the changes will necessarily bleed into 
utility classes etc. I'll do my best to avoid that, but it's not always 
possible.

The idea here is to split the server behavior into systems and 
subsystems, with different implementations that can be mixed and matched.

How far this refactor goes depends on how you guys are using astools 
currently. Odds are most of the changes will be to internal stuff, but 
that's the problem, since astools never had properly hidden internal 
packages. So odds are you're all reaching in and using code all over the 
place.

If you don't tell me what you're using now, odds are I'll break it with 
impunity. If you do tell me, I'll try my best to keep those classes and 
methods there, mark them as deprecated, provide helpful javadoc for 
transitioning, and, in the very end, once everyone converts, I'd clean 
up the cruft. But, if you dont tell me, I'll probably break you when I 
commit it, and it won't be my fault ;)

(If we're being honest, I'll probably break you a little even if you do 
tell me, but that'll be my fault, not yours)

The current ideas for systems is:   publish,  moduleController, 
serverState (previously pollers), startup, shutdown, etc.   I'm also 
trying to work in the idea of extenders able to contribute their own 
systems or subsystems for various configurations or server types, but 
I'm not at that point yet. I am at the point, though, where my desired 
new interfaces conflict with the old poorly designed ones.

Things to tell me that you depend on:
1) Internal Classes
2) CONSTANTS   (IJBossToolingConstants.xyz, or others)
3) API classes
4) depending on server mode (local vs rse)
5) basically everything which could break

Most string constants will not change, but their LOCATIONS might change, 
as many should be internal but aren't.

Anyway, consider this the 'gathering requirements' phase. Let me know, 
or bear the consequences!

- Rob Stryker
I cause problems