Add upper bound to JCL exclusion rule

[bdemers]

JCL now directly supports slf4j and log4j

We don't use JCL, nor do any of our dependencies, so we might want to consider removing this rule from the build. But, it looks like in the past year or so JCL has been updated to work with slf4j and log4j.

Opening this issue more for discussion than anything, commons-loggin 1.3+ also requires java 1.8, but again, we are not using this dep anyway. My take is we should consider removing this rule 🤔

[lhazlewood]

The exclusion rule IMO is so that we don't add it in the future either (accidentally). That is, if anyone issues a PR using it, the build should reject it, since if we go with one it'll probably be slf4j. So my initial reaction is to leave it in for 'enforcement'. Thoughts?

[bdemers]

I agree, that we would want to reject the PR (and continue to use slf4j), but any PR that adds a dependency we should inspect everything it brings in. For example, IMHO, we would want to block anything that depends on guava.

But... there are probably exceptions: if we started maintaining a Guice module, though we would still want to prevent any other sub module from using guava.

IIRC, the big issue originally with JCL was it order to use it with SLF4J, you needed to use one of the legacy adapters (which reimplemented JCL using the SLF4J API), and we wanted to prevent passing that burden onto the users.

There are many dependencies we don't want to bring in, JCL, is just one of them. I'm not sure this rule provides a lot of value to us any more.

That said, it doesn't really hurt either 😄

[lhazlewood]

Makes sense - I don't feel too strongly about it because, as you said, we'd be reviewing the PR for added dependencies anyway.

But since JCL is the only exclusion configured, do you think it'd make sense to remove the enforcer plugin entirely?

[bdemers]

🤔 I do, one less thing in the build (we can always add it back if we need to)
I'll create another PR for that (and ref this discussion)