So, you see problems in some plugins (again, what is the ratio we speak about?) using some frameworks, and then you tell the perfectly valid solution (classloader)...
And regarding slf4j, should I reiterate what Ceki repeated several times? Sorry, but these are non-issues IMHO. Or to rephrase: we have bigger issues to work on, and helping complex plugin writers by removing from them one single burden (to use custom classloader, if must) is really a small benefit, compared to man hours spent on whole topic already. My 5c. T On Fri, Nov 4, 2022 at 1:58 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 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 > > > > > >
