You might want to also consider moving these Launcher classes from org.apache.geode.distributed to some other package such as one of the following:
1) org.apache.geode 2) org.apache.geode.api 3) org.apache.geode.launcher 4) org.apache.geode.management 5) org.apache.geode.process The existing Launcher classes would be deprecated and you could rewrite all Geode code to use new Launchers in the new package. On Mon, Feb 26, 2018 at 11:42 AM, Patrick Rhomberg <prhomb...@pivotal.io> wrote: > Hello, all. > > There has been some discussion [1] on the JIRA regarding GEODE-3584, to > reduce code duplication and improve clarity across LocatorLauncher, > ServerLauncher, and AbstractLauncher classes. > In no particular order, I think the following would be a good starting > point for refactoring these classes: > > * To reduce duplication: > *** Unify ServerLauncher.Command and LocatorLauncher.Command enums to a > single enum. > *** Unify ServerLauncher.ServerState and LocatorLauncher.LocatorState to a > single "MemberState" class. > *** Unify redundancy in ServerLauncher.ServerControllerParams and > LocatorLauncher.LocatorControllerParams to an shared base class. > > * To improve clarity in classes that are currently large: > *** Promote inner classes ServerLauncher.Builder and > LocatorLauncher.Builder to be "top-level" classes. > *** Promote inner classes ServerLauncher.State and LocatorLauncher.State to > be "top-level" classes. > *** Possibly promote inner classes ServerLauncher.ServerControllerParams > and LocatorLauncher.LocatorControllerParams, although the footprint of > each > would be very small after the above refactor. Alternatively, make the > inner class implementations > > Each of these refactors would require deprecation of existing public-facing > points and delegation at those points to the new classes. > > The above are initial impressions. I haven't spent much time digging into > the viability of each refactor, but it does appear that the inner classes > do not heavily rely on visibility of class fields that would be otherwise > inaccessible. > > Thoughts or concerns on these API relocations? > > Imagination is Change. > ~Patrick Rhomberg > > [1] https://issues.apache.org/jira/browse/GEODE-3584 >
