Auto-generation of config Models?
dward Mar 1, 2011 12:54 PMWhile I was going through and tediously adding javadoc comments to all the config Models, the obvious slapped me right in the face: This is all incredibly BOILERPLATE code. There is no reason that we should have to code this, and maintain them in git.
What I would like to do is write a maven mojo (representing another maven goal) for our switchyard plugin. One that generates the Models for us from the XSDs that we already have in place. This would be part of the generate-sources phase (or whatever it's called in maven) of the build.
Now, my second thought was, "Ummm... why aren't we using JAXB and it's source generator for this config stuff again?" There are still very valid reasons:
- The lower-level Configuration API (which resides underneath the higher-level Model API) is very flexible, and allows developers and users to ad-hoc extend and use config sources without ever needing to write a Model in the first place. JAXB doesn't have this.
- Still providing the BaseModel functionality allows developers and users to override anything generated, or even write against it without generation if they don't want everything the generation does. And they will STILL get the benefits of the marshalling features. JAXB doesn't have this.
- An important feature of the Configuration and Model codebase is auto-merging. This is something we depend upon when our Model Scanners return their results to the ConfiguratorMojo, and it needs to merge all the model data. JAXB doesn't have this.
- The code required to marshall/unmarshall Configurations and Models is one line. JAXB isn't too hard to use, but it's more than one line.
- The namespace-based versioning features of the Model APi is pretty powerful. Honestly I'm not sure what is available in that regard from JAXB.
- The Configuration and Model codebase is not dependent upon an XML representation. Yes, we currently only have 1, which is DOM-based, but that is hidden from the rest of the code. JAXB is XML-only.
There's probably more reasons, but I think the above is sufficient.
One other thing I would like to do as part of this work is somehow get rid of the "v1.V1" stuff. I need to give some thought for how we can future-proof as much of our model-dependent code, but what I do know is that the "v1.V1" stuff feels hokey when you're coding against it.
I was first thinking that my time-estimate to do the above work would be 3 days or so, but you know how that goes, so I would want to be given a week to do it.
Comments and criticism welcome, as always.