[logback-dev] Logback source code organization and extensions

[ceki]

Hi Les,

Thank you for considering making a contribution to the logback
project.  The modularization scheme for logback extensions you propose
sounds quite reasonable. However, I should mention that logback is
already split by logging event type (logback-access, logback-classic)
with logback-core providing shared code, applying the
core/classic/access separation to the modularization scheme for
logback extensions, we could end up in 18 (=3x6) modules
(core/access/classic x extensions/json/commmon/groovy/jackson/loggly/). 
If logback-classic is the only target for logback-extensions, this
combinatorial problem obviously does not apply.  To keep things
simple, we could ignore logback-access and concentrate on extending
only logback-classic.

More importantly though, I personally cannot and do not wish to commit
to the maintenance of logback-extensions. Thus, I would prefer to
support logback-extensions as a separate project as far as the code is
concerned. However, at the web-site level (http://logback.qos.ch), the
two projects could be integrated by allowing you to manage on your own
the branch under say http://logback.qos.ch/extensions/.

Thoughts?

-- 
Ceki
http://twitter.com/#!/ceki

On 08.03.2012 20:40, Les Hazlewood wrote:
> 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,
>