Le ven. 4 nov. 2022 à 13:17, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Howdy, > > Will we keep asking the same questions over and over again? Until we get > the "wanted" answer? > > Maven core and ecosystem uses SLF4J API. Full stop. > > Just use SLF4J API, and you will get a pre-configured back-end as well. > Done. > > Now,. this story keeps popping up: "plugin developers using framework...." > begs the question: > what framework are we talking about? And how common is this story? What > percentage of Maven > plugins USE a "framework"? > All plugins with a dependency on slf4j are concerned and best ones use workarounds (custom classloader instead of mojo one) others can be broken by default (exec:java maven plugin needed a dedicated config for that case for ex). To cite a few: tomee, spark, cxf, camel, openapi/swagger ones, plus all the ones invovling user code with slf4j (most end *apps* included - you like it or not like me ;)). Indeed the mojo copying a file will not be impacted but it is quite rare these days to not have a build with at least one of these plugins. We also have the big issue we reported years ago that we leak slf4j for mojo (maven-core/extensions.xml) so we enforce the slf4j version, API and public API whereas we have mojo designed to do what they need to do the way they want. Exactly like we dropped cdi-api because it was breaking more than helping, slf4j is at the same position - whatever its own quality when used outside a pluggable system. So yes, leaking *any* not maven owned API is an issue, slf4j is just ultra visible due to its past adoption. If it helps, we got the same topic at tomee (with log4j1 at that time) and the move to JUL was leading to the same kind of thread but after the change we got way less logging issues and related bugs and not much complains, so I think it was the right choice and since maven architecture hits the same kind of pitfalls I think the same outcome would be beneficial. > > my 5 cents. > T > > On Fri, Nov 4, 2022 at 11:56 AM Slawomir Jaranowski < > s.jaranow...@gmail.com> > wrote: > > > Hi, > > > > I want to start ( again :-) ) a discussion about logging in Maven > plugins. > > > > First I agree that plugin developers should use logging methods provided > by > > Plugin api. > > > > But we can not expect plugin developers to write everything from scratch. > > In many cases they may want to use an external library to do tasks needed > > by the plugin. > > > > We don't have any control over what logging framework is used in the > > external library used by plugin developers. > > > > We also maintain some libraries which can be used by plugin and also as > > standalone in another project. > > In such a case the question is - what logging we should use [1]? > > > > Last time I did a test, I use Java util logging from JDK in the Maven > > plugin. > > I see that Java util logging use default configuration, eg. we will have > > two lines for one log event. > > Even more options -q and -X have no effect for such a logger. > > > > One of the solution for such problem is using "Bridging" methods > supported > > by slf4j [2] > > Probably all of existing and future logging frameworks can not be > covered - > > but most of common using will be. > > > > I hope that, even if we will want to change the logging framework used > > internally in Maven, we can also use the same method. > > > > [1] https://github.com/apache/maven-dependency-analyzer/pull/71 > > [2] https://www.slf4j.org/legacy.html > > > > > > -- > > Sławomir Jaranowski > > >
