All algos implementations are self-contained in their dedicated hex.[algo] package except for StackedEnsemble, whose Mode class was created in the root hex package.
This creates various weirdnesses and bad practices:
counter-intuitive Java API: StackedEnsembleModel not being in its package.
cross-package circular dependencies: circular dependencies prevents or makes much harder later code refactoring and leads to spaghetti code due to tight coupling between packages.
access to internal methods of Model class that are not visible outside hex package: this is due to the fact that ensemble models also need to manipulate base models: changing the visibility of those methods is not a good idea either as Model is part of the Java API: this mainly appears in .
as a consequence of the last 2 items, this broadens the visibility of some internal methods of StackedEnsembleModel to public as they're needed by Metalearner, making those methods de-facto part of Java API...
Finally, moving the StackedEnsembleModel to hex.ensemble package will force us to fix the implementation of its predictScoreImpl method which bypasses some of the logic usually applied when scoring models.