Agree for option (disagree it is not common but that's not important) just because there is no real choice else we would need to handle all libraries and all versions which is clearly a no go for me.
Just a side note on the shared code: fully agree until log is exposed in the API and can be reused accross plugins. Otherwise +1 for this compromise. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 4 nov. 2022 à 18:42, Slawomir Jaranowski <[email protected]> a écrit : > 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 <[email protected]> > 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 <[email protected]> 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 < > [email protected] > > > > > > wrote: > > > > > > > Le ven. 4 nov. 2022 à 13:17, Tamás Cservenák <[email protected]> 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 < > > > > > [email protected]> > > > > > 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 >
