rmannibucau commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1842577827
@cstamas > bet 99.999 of our users use logger just for that 99.99% uses Log facade (most of plugins just wire the logs to this interface since it is the only one in maven api today). Just review github and our own mojo for ex. Very few use slf4j since it was done in a very recent maven release and most of plugin still comply to older api too. > Take away simplicity and availability of SLF4J API only due someone somewhere fiddles with logging implementations Think you miss the fact SLF4J is an *implementation* for us and a detail we don't want to support for years cause as explained in the related threads slf4J is *not* stable and already bite several asf project so we must only promote *as api* something we control, this is a pure design and experience perspective. If I'm following your reasoning we should just expose maven/lib to mojo and I agree it is trivial to agree this is bad but all libs are available and I don't think we use anything hard to consume so I don't think this reasoning can last very long. > merge this PR to not encourage people to use slf4j since we agreed it was wrong a long time ago now Ok, let me rephrase: "since using slf4j was agreed to be wrong, let's not deprecate the only API we have and control and we'll bridge to mvn4 api". The "there was never consensus" was on "moving to slf4j as api", this was never discussed nor agreed so revert is the minimum we can do. > For me this PR is bicycle shedding at it's best. As explained this deprecation is a bug and was *not* intended so we should just fix it, after we can rediscuss what we do if you feel it was right but as of today this merge shouldn't have happent. Agreement was on maven core code which can use slf4j as primary API, never ever on mojo - agreement was actually the opposite. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
