[_pmf_]

I found that a sweet spot between wiring-by-code and wiring-by-container-and-configuration-dsl is using a dynamic language for wiring (say, Rhino, which is very lightweigth): you have the flexibility of wiring-by-code and can easily change the configuration purely by deployment (without recompiling anything)

[RyanZAG]

Just curious, but what's wrong with recompiling? If you make a typo in your Rhino file on production, your whole app is now failing. Surely it makes more sense to just take the 5 minutes to recompile (or hopefully 30 minutes and test it out in dev first)?

I don't really understand what problem using the dynamic language is trying to solve there, and you've just added in a whole new branch of different code that won't work with static analysis, and will need to be maintained in addition to your normal code.

[_pmf_]

In my case, I have an Eclipse-based product (toolchain for embedded development) that must be reconfigured per client or even per project (on site); i.e. it is more about dynamically creating very specific variants of a product. Using client/project-specific plugins would be the alternative for me, but this has much more overhead.

[RyanZAG]

Are you not packaging un-used code into your embedded binaries then? You'd also have to manually test the reconfigured client before deploying it, I think.

Seems better to make an automated build system off a database of configurations - a simple sql table with the different settings that could automatically build versions for all clients. You'd get static compile time checking of each build, and it would allow for easily running automated tests against each client's version.

So you'd end up with no un-used code, a database of client configuations, and static compile time checking. Seems win-win.

Sorry for 'assuming your problems', feel free to ignore. Interesting situation though.