Tim Allison, I accept using JUL in tika-core since we have no deps there (and will have only commons-io at some later point). And bringing slf4j-api may be worth considering if we will use external deps in core anyway. At least discussable thing, I guess.
But I'm against using JUL in tika-parsers: it's hard to configure, it cannot be directed to other logging backend without using jul-to-slf4j, it have extra runtime cost like string concatenation and calling toString() for any object which state is logged.
Anyway, we'll always have deps which use JUL, commons-logging-api and slf4j-api because logging api choose is up to upstream developers in their libs. Why not use common and present dependency to log anything through it?
When I use Tika in my downstream projects I configure logging as I described at wiki page: logback-classic as impl (usually runtime dependency) and jul-to-slf4j, jcl-over-slf4j, log4j-over-slf4j to forward all other logging frameworks apis via slf4j-api to logback. It works perfectly, has one point to configure etc.