Hi, The Settings framework is very nice: there are no dependencies to the framework itself anywhere, so you can run with both the Setting Browser and *the framework itself* unloaded. All the settings definitions are in their own packages, so you can even unload *those*. But I wonder if that is not one thing too much: -> the definition itself does not create dependencies at all -> the definitions are *tiny* (5-30 line methods) -> the packages contains just one class with (often) just one method, managing a complete package for that should pay of, and I would say it does not (âI can save 500 bytes of dead code by not shipping the settings definition in my deployment image!"). I guess nobody ever unloaded a settings package for deployment! (#cleanUpForProduction does not) I would like to move the definitions of settings close to the code that the settings manipulate (and from itâs own class just to the main class of that package, class side). - you can still unload the settings framework after - the only âuselessâ things staying in the system after unloading the settings framework is a method that is not used (but that does not introduce dependencies) - managing the code base in turn gets simpler - less classes and packages to manage Marcus