The Configurator class is just one big spaghetti ball of code. There needs to be a cleaner way to get the configuration params either from the XML or from the CLI into the xunit file or into the config file itself. I think that pong's way of using a transformer pipeline was more elegant (although it had a few marring jars of ugliness, but it's still way better than what's in polarize).
Another piece of ugliness, is that it doesn't have a "module" system for the CLI args (ie, a 2 level system of configurator module_subsystem command similar to subscription-manager or the new docker CLI). So to edit the xml-config, you have to add --edit-config true, otherwise it assumes it will edit the xunit file. That's just ugly.
So we need to do the following:
Make the parser work on a module system
Pass the configuration through a pipeline of transform classes, where each transform takes a set of immutable data, and returns an immutable set of data
XMLOpts --- base ---> ENVOpts ---transform---> CLIOpts ---- transform ----> Final data to be used
rarebreed
commented
7 years ago
The Configurator class is just one big spaghetti ball of code. There needs to be a cleaner way to get the configuration params either from the XML or from the CLI into the xunit file or into the config file itself. I think that pong's way of using a transformer pipeline was more elegant (although it had a few marring jars of ugliness, but it's still way better than what's in polarize).
Another piece of ugliness, is that it doesn't have a "module" system for the CLI args (ie, a 2 level system of configurator module_subsystem command similar to subscription-manager or the new docker CLI). So to edit the xml-config, you have to add --edit-config true, otherwise it assumes it will edit the xunit file. That's just ugly.
So we need to do the following:
XMLOpts --- base ---> ENVOpts ---transform---> CLIOpts ---- transform ----> Final data to be used