logback-core dependency should have `provided` scope

Given that logback-core is indeed provided at runtime and README clearly states that as a (rather obvious) requirement, it would be cleaner to classify the former as provided-scope dependency.

This would also allow various custom/in-house libraries that extend logstash-logback-encoder to avoid introducing logback-core as transitive compile-scope dependency into their customers’ class path (currently one has to specifically exclude logback-core to achieve that).

[yborovikov]

Hi @philsttr, thank you for your detailed explanation!

Striking a balance between convenience and correctness/flexibility is often a tricky challenge, indeed. In this particular case, however, it might be quite simple.

The reason is that for the majority of logstash-logback-encoder consumers (using it for logging) the consumers would still have to explicitly declare either logback-classic or logback-access (or both) as their runtime scoped dependencies - simply relying on the transitive logback-core dependency of logstash-logback-encoder would not be enough in most cases I can think of (is there a popular way to use pure logback-core directly?).

Given that (and the possibility of logback-core version mismatch between customer customer-declared logback-classic and the one potentially coming from logstash-logback-encoder), I would argue that categorizing logback-classic as provided scope (in this library) would not harm the convenience, at all, in the typical basic use case.

[yborovikov]

Thank you!