Hi Ceki (et. al), I'm trying to wrap my head around making it easy to add and support contributions/extensions to logback in a clean/modular way. For example, I'd like to see a JSON formatter and a Loggly appender added to Logback. However, these additions probably don't make sense to be added to logback core/classic as they would bloat the library for those not using these features. As such, it makes sense (to me at least) to have a more modular source code organization where different features/extensions are represented as a dedicated Maven module. This way, people can easily (and deterministically) use a respective dependency depending on the feature they wish to enable. Clean and easy. Now, with regards to a JSON formatter and a Loggly appender (which would likely use the JSON formatter), I'd envision something like this in the Logback source tree: logback/ logback-access/ logback-classic/ logback-core/ ... logback-extensions/ Where 'logback-extensions' is a new Maven module. It would just be a wrapper module containing children. Below it, you might see the following: logback-extensions/ json/ common/ groovy/ jackson/ loggly/ foo/ bar/ ... In the above example, the logback-json module: 1) provides a 'common' sub module where JSON-specific needs are defined, and 2) has other sub-modules depending on _how_ you want JSON to be formatted. You can depend on the logback-json-jackson dependency if you want to use Jackson, or you can depend on logback-json-groovy if you want to use the built-in JSON support in a Groovy 1.8+ environment. The 'loggly' extension could depend on logback-json-common. The idea is that you can depend on a dependency that is copacetic with your intended runtime environment. I think this makes a lot of sense - we use it in Apache Shiro (http://svn.apache.org/repos/asf/shiro/trunk/support/) and it works very well for us. Before I go off and create my own 'logback-extensions' project on GitHub, I'd rather contribute this back to Logback proper as a pull request if this is something you are willing to implement. Thoughts? Cheers, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 PMC Chair, Apache Shiro | http://shiro.apache.org twitter: @lhazlewood | http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com