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