Re: Revising PluginDetail JMX Methods
Jeffrey Fredrick <[email protected]>
| Newsgroups | gmane.comp.java.cruise-control.devel |
|---|---|
| Message-ID | <[email protected]> |
I think backwards compatibility is important. I haven't looked at the design of PluginInfo and PluginDetail, but shouldn't there be a way to have any legacy interface methods delegate to the new ones? That give us backwards compatibility without duplicating implementation, yes? Jtf On Sat, Oct 30, 2010 at 4:47 PM, Seth Pollen <[email protected]> wrote: > I guess if we want to keep full backwards compatibility, we should just > leave the JMX interface alone. The motivation for my original suggestion is > that the old PluginDetail classes could be merged with the new PluginInfo > classes, reducing the duplication of functionality. But if we want to keep > backwards compatibility, we need the PluginDetail classes, and adding more > methods to use PluginInfo would be work without any real driving reason > behind it. > > But I am currently working on the CC-Config project, and I know that it is > undergoing a major rewrite, which would give us the opportunity to jump to a > new JMX interface if a one was introduced. > > [ Seth Pollen ] > > > > On Fri, Oct 29, 2010 at 10:31 PM, Jeffrey Fredrick < > [email protected]> wrote: > >> >> Would this impact the RMI interface? >> >> This tool is the major one I'd worry about for backwards compatibility: >> >> http://cc-config.sourceforge.net/ >> >> My bias would be to keep backwards compatibility. Could you add new >> methods or add equivalent methods with alternative names with the new return >> types? >> >> Jtf >> >> >> On Fri, Oct 29, 2010 at 3:40 PM, Seth Pollen <[email protected]> wrote: >> >>> Hello all, >>> >>> Currently, there are a few methods in the JMX interface that return >>> PluginDetails. As a part of CC-202<http://jira.public.thoughtworks.org/browse/CC-202>, >>> we have introduced a new class (PluginInfo) that provides a fuller set of >>> behaviors and includes most of what was provided by PluginDetail. I think it >>> would be good to merge these two classes together, but that would involve >>> changing the return types of some JMX methods (such as adding and renaming >>> methods in PluginDetail). Will that break existing tools which use the JMX >>> interface? Is that an acceptable problem that we can deal with? >>> Thanks. >>> >>> - Seth >>> >> -- CITCON Continuous Integration and Testing Conference http://www.citconf.com/ ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Cruisecontrol-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cruisecontrol-devel