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

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 _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJem2EACgkQcthLMIwdEb0v9ACg3bv5m73BtOt638x2F6D5xOQX h10AoKYmYnx1Q8jTEhCeVf0T4kMasduJ =MZkj -----END PGP SIGNATURE-----