[ 
https://issues.apache.org/jira/browse/MNG-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17584306#comment-17584306
 ] 

ASF GitHub Bot commented on MNG-7532:
-------------------------------------

rmannibucau commented on PR #793:
URL: https://github.com/apache/maven/pull/793#issuecomment-1225848083

   > The client facing API of SLF4J is stable and has been stable since version 
1.0. 
   
   Not really 1.5->1.6  were not compat for ex (LocationAwareLogger#log, 
MessageFormatter, etc...). It hurt several apps already.
   So even I agree it is generally stable, it is not something we can assume 
for our *api*.
   It also increase the work needed to stay compatible since we have our own 
binding.
   
   It is really not "is slf4j bad" topic - in particular since it is fine to 
use it in @apache/maven core modules - but simply a design issue (we could 
workaround technical details if we would like to use it on a pure technical 
side), we should own our API to ensure mojo and extensions are reliable in time 
and not highly unstable (like gradle had been and was forced to introduce the 
wrapper to workaround it).




> Revert MNG-6931 deprecation since list shows no consensus on that
> -----------------------------------------------------------------
>
>                 Key: MNG-7532
>                 URL: https://issues.apache.org/jira/browse/MNG-7532
>             Project: Maven
>          Issue Type: Task
>            Reporter: Romain Manni-Bucau
>            Priority: Major
>
> There are several threads on the dev list asking for the drop of slf4j and at 
> least keeping a logging abstraction for not internal dev (= core can use 
> slf4j but not mojo/extensions).
> Work is being done to abstract plugin api so let's keep the 
> deprecation/replacement of our Log API in this track and keep it the official 
> way for now.
> one of the multiple refs: 
> https://www.mail-archive.com/dev@maven.apache.org/msg123452.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to