[logback-dev] Logback Refactoring Ideas

[Chad La Joie]

Maybe I just haven't encountered them but I've never seen a case where 
projects would have benefited from this type of fine grained packaging. 
  So at the very least I would think that the first four packages you 
identify should be one package.

As far as the versioning goes, I would recommend against independent 
versions unless you are going to establish a consistent and rigid 
versioning policy dealing with API changes and backwards/forwards 
compatibility.  To date logback has not had that and if it doesn't in 
the future you'll end up having to describe exactly which versions of 
which packages work with exactly which versions of other packages.  That 
would be very cumbersome and messy I think.

On 9/1/10 3:01 AM, Gunnar Wagenknecht wrote:
> Greetings Logback developers,
>
> I'm regularly packaging Logback OSGi bundles for Eclipse Orbit. The
> other day I was wondering if the current core vs. classic split of
> Logback is really useful for people, i.e. is anybody out there using
> _just_ Logback core without any of the classic pieces?
>
> For example, PatternLayout is classic but the file appenders are in
> core. Isn't PatternLayout an essential logging element? Also, when an
> issue in the XML/Groofvy configuration implementation is detected, a
> full new release of core+classic is required. Wouldn't it be better if
> the parts could evolve independent?
>
> Thus, I was thinking of a more fine grained split based on functional
> units. For example like this:
>
> ->  Logback Logging Essentials
> All the essential logging related stuff form core+classic (logger,
> levels, (turbo) filters, console appender, encoders, layouts, basic
> configurator)
>
> ->  Logback SLF4J Logger
> The native SLF4J logger.
>
> ->  Logback XML/Groovy Configuration Pack
> The advanced configuration functionality based on Joran for XML + Groovy.
>
> ->  Logback File Logging Extension Pack
> File appenders
>
> ->  Logback Web Extension Pack
> Servlet integration, HTML appenders, etc.
>
> ->  Logback Enterprise Extension Pack
> Advanced appenders (JMS, Database), JNDI stuff, etc.
>
>
> There could be other extension packs as well. The challenge IMHO is to
> collect all the essential things together for having a really small
> Logback package that contains only the minimum required for logging (to
> console and to files). Maybe the file logging package can be part of the
> essential package.
>
> Anyway, another important point is that the packages are released
> independently, i.e. get their own version. Thus, when an issue in the
> XML/Groovy configuration package is detected, no new release of the
> essential pack is necessary.
>
> There can still be joint releases of all packs together (for example, to
> have a better brand recognition) - the "Logback 1.2" release. But in
> this case, Logback 1.2 means essentials 1.0.4, slf4j-logger 1.0.1,
> configs 1.2.0, file logging 1.1.24, etc.
>
> Thoughts?
>
> -Gunnar
>

-- 
Chad La Joie
http://itumi.biz
trusted identities, delivered