True but JUL is also there since more time, no? More seriously I think most plugins stick to getLog and bridge the output cause otherwise the behavior is often undefined depending the stack.
For ex, exec:java maven plugin generally breaks slf4j binding, so most impl caring of logs (:run) just forward it to the secured api which is Log. If we want to discuss plugin logging api i think we need another thread but i wouldnt pick slf4j. Le dim. 31 mai 2020 à 21:35, Sylwester Lachiewicz <slachiew...@gmail.com> a écrit : > Just note - we already have SLF4J API from Maven 3.1 [1] available for all > plugins since 2013. > > Sylwester > [1] http://maven.apache.org/maven-logging.html > > > niedz., 31 maj 2020 o 20:49 Xeno Amess <xenoam...@gmail.com> napisał(a): > > > I like slf4j. > > But slf4j can cause dependency hell as it really lack something > > named backward compatibility. > > I met that thing in one of my repo. > > Really bad experience for me. > > > > Romain Manni-Bucau <rmannibu...@gmail.com> 于2020年6月1日周一 上午2:35写道： > > > > > Hmm,we are already bound to slf4j simple logger by conf and we dont > want > > to > > > break it so less costly is slf4j, will avoid to reimpl the binding > > (needed > > > with jul and log4j)...but does not solve all issues with plugins and > > > conflicts (jul would). That said not sure we can do better without a > huge > > > investment not worth it so let's clean things a bit if we can or just > > keep > > > it as it since it does not hurt at all IMHO. > > > > > > Le dim. 31 mai 2020 à 20:24, Gary Gregory <garydgreg...@gmail.com> a > > > écrit : > > > > > > > I'm sure you all know that Apache's own Log4j 2 has it's own API > facade > > > > with a backing implementation and bridges to other logging systems > like > > > > SLF4 and Logback, and Java Logging. Not only that but it is actively > > > > maintained by more than a single BDFL (like yours truly) I won't > > debate > > > > the pros vs slf4j... > > > > > > > > ;-) > > > > > > > > Gary > > > > > > > > On Sun, May 31, 2020, 13:41 Robert Scholte <rfscho...@apache.org> > > wrote: > > > > > > > > > Some pro's and cons: > > > > > > > > > > There have always been concerns about SLF4J, especially because it > is > > > > > maintained by only one person. > > > > > Although Ceki did help us to make Maven work well with SLF4J, it > > still > > > is > > > > > a risk. > > > > > Depending on third party libraries always comes with a risk. > > > > > Having our own logging interfaces (I don't consider plexus as a > third > > > > > party library, as it is maintained by Maven developers) means could > > > > switch > > > > > to another framework at any time. > > > > > That said, we might even switch to the Java Logging Framework, as > > > > > available since Java 1.4 > > > > > > > > > > On the other hand, SLF4J has become the leading standard, so even > in > > > the > > > > > worst case scenario I expect there will a way to keep using the > > current > > > > > SLF4J API. > > > > > > > > > > One of the benefits of dropping Plexus Logging is getting rid of > > > > > the AbstractLogEnabled and LogEnabled classes, which bind the > > > components > > > > > very strict to the Plexus logging framework. > > > > > > > > > > thanks, > > > > > Robert > > > > > On 31-5-2020 19:21:51, Elliotte Rusty Harold <elh...@ibiblio.org> > > > wrote: > > > > > To be clear, my proposal is not to do anything to the plexus > logging > > > > > API or the code in the plexus project. I simply would like to > chamge > > > > > some Maven code to call SLF4J instead of Plexus logging. > > > > > > > > > > On Sun, May 31, 2020 at 12:43 PM Romain Manni-Bucau > > > > > wrote: > > > > > > > > > > > > If it does not break mojos (thinking to getLog API) +1 from me, > > > > > otherwise I > > > > > > would be -1 until a compatibility module is properly added to the > > > > distro. > > > > > > > > > > > > Romain Manni-Bucau > > > > > > @rmannibucau | Blog > > > > > > | Old Blog > > > > > > | Github | > > > > > > LinkedIn | Book > > > > > > > > > > > > > > > > > > > > > > > > Le dim. 31 mai 2020 à 18:38, Tamás Cservenák a écrit : > > > > > > > > > > > > > +1 to rip out plexus logging > > > > > > > > > > > > > > On Sun, May 31, 2020, 17:58 Elliotte Rusty Harold > > > > > > > wrote: > > > > > > > > > > > > > > > Moved from slack per suggestion: > > > > > > > > > > > > > > > > The documentation on logging for Maven seems of two minds: > > > > > > > > > > > > > > > > "Maven uses [Plexus logging API][6] with basic Maven > > > implementation > > > > > > > > writing to stdout. > > > > > > > > We have reached the decision that SLF4J is the best option > for > > a > > > > > > > > logging API: SLF4J has reached a certain level of ubiquity > and > > > > while > > > > > > > > SLF4J may not be perfect, it's the de facto standard and it's > > > > > > > > pointless to try and remake another one. There are many > > > > > > > > implementations to choose from, including Logback and Log4j2. > > All > > > > the > > > > > > > > hard work has been done. All the bridges and funnels for > other > > > > > systems > > > > > > > > function well, which allows others to use whatever logging > > > > > > > > implementation they like in their components, while still > being > > > > able > > > > > > > > to have integrated logging." > > > > > > > > > > > > > > > > Does this mean we can rip out the Plexus logging API and > > replace > > > it > > > > > > > > with SLF4J? In at least one plugin, the plexus logging API > > pulls > > > > in a > > > > > > > > lot of plexus code we wouldn't otherwise need. > > > > > > > > > > > > > > > > -- > > > > > > > > Elliotte Rusty Harold > > > > > > > > elh...@ibiblio.org > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Elliotte Rusty Harold > > > > > elh...@ibiblio.org > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > >
