> Maven Plugin code should use Plugin Api for logging purpose > In shared libraries used by Maven and maintained by us - we will use SLF4J directly
I asked to be allowed to put this on the logging site, but we never had consensus of this. I agree 💯 here, but ut really needs to get documented. I saw dozens of plugins switching from Maven's logging API to slf4j directly - which is probably not what you wanted. But at least we now have it written down. 🙂 I hope everyone agrees on this. If so, let's make it official by updating the documentation. - Ben On Fri, 4 Nov 2022, 18:42 Slawomir Jaranowski, <s.jaranow...@gmail.com> wrote: > Once again thanks for feedback. > > In order to finish discussion and not return to this topic again I will try > to update documentation about logging in Maven plugins ... so I see the > message, as Tamás wrote > > - Maven core and ecosystem uses SLF4J. > - Maven Plugin code should use Plugin Api for logging purpose > - In shared libraries used by Maven and maintained by us - we will use > SLF4J directly > > One case which I would like to discuss was when plugins use something other > than SLF4J, directly or by using an external library. > To support proper logging we need forward events to SLF4J. > > So I see two ways: > 1. support forwarding log event from another library to SLF4J by Maven core > itself > > 2. let responsibility of log event forwarding will be on Plugin developers > > Personally I'm for the second option - it is not a common case, so > developers can do it if really needed. > > Finally should be documented and will be clear, discussion will be > finished. > > > pt., 4 lis 2022 o 15:08 Romain Manni-Bucau <rmannibu...@gmail.com> > napisał(a): > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > -- > Sławomir Jaranowski >
