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
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
