[logback-dev] Logback Refactoring Ideas

[Gunnar Wagenknecht]

Am 01.09.2010 12:50, schrieb 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.

I put the ideas together because we would benefit from them. Our project
just need the logging essentials but not the XML/Groovy configuration
stuff or any of the other appenders. However, there were releases in the
past that just contained modifications in those area and we were
confronted with requests to updated an "outdated" version for Logback
which actually wasn't outdated.

I can also see some benefits on embedded devices which look for ever kB
they could save.

> 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.

I don't really see this as an issue. There are well established best
practices for versioning as well as defining requirements, etc. Maybe
I'm wrong but to me it seems that Ceki already started adopting them for
SLF4J and also for Logback (that's why it's still pre-1.0 to allow
evolution of the API).

Another benefit is that Logback Essentials could be declared 1.0
independent from other packages. IMHO this would also be a positive
signal to the community. And, as I said before, although the packages
may have individual versions they could still be released as one
convenience drop.

-Gunnar

-- 
Gunnar Wagenknecht
gunnar at wagenknecht.org
http://wagenknecht.org/