Lumberjack

This is a full logging library with a build in way to log to console, file or any custom place as well as optional extensions to send a log file via mail or show it on the device.

Features#

simply lazy evalution based logger based on a L class for the shortest possible log codes
easily extendible with custom loggers
offers console and file logger implementations
supports log filtering
providers a viewer for log files

Supported Platforms#

This is a KMP (kotlin multiplatform) library and the provided modules do support following platforms.

Module	android	ios	windows	macos	wasm	Info
Core
`core`	✔	✔	✔	✔	✔
Lumberjack
`implementation-lumberjack`	✔	✔	✔	✔	✔
`logger-console`	✔	✔	✔	✔	✔
`logger-file`	✔	✔	✔	✔	-
Extensions
`extension-composeviewer`	✔	✔	✔	✔	-
`extension-feedback`	-	-	-	-	-	(1)
`extension-notification`	-	-	-	-	-	(1)
`extension-viewer`	-	-	-	-	-	(2)
Timber
`implementation-timber`	-	-	-	-	-	(3)
`logger-timber-console`	-	-	-	-	-	(3)
`logger-timber-file`	-	-	-	-	-	(3)

(1) notification and feedback module are android specific modules and therefor only support android
(2) the viewer module is and older view based module that just supports android based on its nature
(3) timber is only supported on android and therefor those modules are android only modules as well

Demo#

A full demo is included inside the demo module, it shows nearly every usage with working examples.

Notes#

Timber vs Lumberjack implementation#

This library fully supports Jack Whartons Timber logging library (v4!). And was even based on it until Lumberjack v6. Beginning with v6 I wrote new modules that work without timber which leads to a smaller and more versitile non timber version. I would advice you to use the non timber versions but if you want to you can simply use the timber modules I provide as well - whatever you prefer.

Why did I do this?

I decided to not use Timber myself anymore because of following reasons:

Timber does explicitly rely on non lazy evaluating logging - it was a decision made by Jack Wharton and was the main reason to write Lumberjack at the beginning
Timber is restrictive regarding class extensions - in v5 I would need access to a field to continue supporting timber in Lumberjack
Timber is considered as working and feature requests and/or pull requests are not accepted if not really necessary - like e.g. my minimal one here.
additionally I always needed to extend the BaseTree from Timber because of the limiting restrictions of the default BaseTree as well as it was to restrictive to make adjustment in it ( I always had a nearly 1:1 copy of it inside my library here). This was needed to allow to adjust the stack trace depth so that Lumberjack will log the correct calling place as a wrapper around Timber.

This lead to my final decision

Lumberjack does not need Timber and I provide a way to plug in Timber into Lumberjack now - this way using Timber and Lumberjack in combination is possible but not necessary anymore.