> perfectly valid solution (classloader) This is a workaround any plugin developer hates to be honest. Guillaume started to make the plugin ClassRealm more customizable, this can be an option but still, means we don't leak slf4j. I fully agree the issue is how we expose it to plugins and extensions since for the core codebase we don't care which solution we use but it just moves the choice to the later stage and lead the same solution.
In terms of biggest issue I guess it is the ones people face, logging is a common one, not sure others you have in mind but this one and classloader are the two biggest from what I saw, rest are enhancements and nice to have from my window. My 2cts indeed Le ven. 4 nov. 2022 à 15:00, Tamás Cservenák <ta...@cservenak.net> a écrit : > 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 > > > > > > > > > >
