Generated config considered harmful?
kcbabo Apr 25, 2012 9:46 AMFigured I would throw this subject out there and see what kind of arguments we can get in. At present, we support the generation of configuration based on annotations in the user's project structure. This means that the effective configuration of an application consists of two pieces:
1) The "source" config. This is the SCDL specified directly in src/main/resources/META-INF/switchyard.xml.
2) The "generated" config. This is what we generate off of annotations in the project.
At build time, #1 and #2 are merged to become the effective configuration of the application. This config is placed in target/classes/META-INF/switchyard.xml.
The above model works fine, but there are a few cases where I think it's suboptimal:
- Quickstarts/Examples - I believe that users want to see the "whole picture" when they look at an example. As things stand now, someone looking at a quickstart needs to build the quickstart and then know to look in target/classes instead of src/main/resources to see the effective configuration for the application.
- Tooling - our experience with the Eclipse application modeler suggests to me to that having two separate configurations will create no end of confusion in the tooling. If the application model includes only user config, then you won't see generated stuff, but everything in the picture is editable. If the application model includes generated config, then you 'see' the entire application, but certain pieces of the model cannot be edited.
I like the idea of generated config, but I'm beginning to think it's counterproductive in the cases outlined above. Therefore, I suggest we switch to a model where tooling generates user configuration for everything. I also suggest we update all of our quickstarts to include a complete user configuration. Keep in mind, that generated config is still available as an option, but we won't default to that in our quickstarts or our Eclipse/Forge tooling.
Thoughts? ;-)