Le dim. 31 mai 2020 à 23:26, Benson Margulies <[email protected]> a écrit :
> We made a community decision years ago to support slf4j. It's not helpful > to cast aspersions on it. If someone wants to lead an effort to supplant > that with log4j now that it's alive again, or even jul (please, no), > someone can start that process. Until then, using slf4j in an plugin is an > approved and reasonable decision, I think. > I don't think so, most plugins don't respect that. Maybe it got discussed and approved years ago but it hasn't been done nor ack by the users AFAIK. And I think it would be a pain cause then we can't fix all the bugs we have with SLF4J currently due to its binding/SPI design - guess we must enhance our own binding anyway to support to ignore itself to use a user provided one? So overall: +1 to clean up any internal from plexus but we should keep in mind we must not expose SLF4J in *plugins* - once again it sounds like 2 topics even if it could be a single one to unify the logging in the whole maven project. > > > On Sun, May 31, 2020 at 2:00 PM Elliotte Rusty Harold <[email protected]> > wrote: > > > I'd be happy to use JUL instead if that works better. No extra > > dependencies at all, and presumably no version conflicts. > > > > For the moment I'm not proposing any major changes to existing APIs, > > aside from perhaps marking some classes no longer implement > > AbstractLogEnabled. My question is when we have the typical logging > > cases in a plugin or library, i.e. > > > > 1. An exception is thrown and we want to log an error > > 2. We want to print some output from the plugin on the console > > > > What API do we invoke? The simplest thing we could possibly do is call > > > > Logger.getAnonymousLogger().warn( "message", ex ); > > > > but whatever folks prefer is fine with me. > > > > > > > > On Sun, May 31, 2020 at 3:41 PM Romain Manni-Bucau > > <[email protected]> wrote: > > > > > > 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 < > [email protected]> > > 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 <[email protected]> > > 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 <[email protected]> 于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 < > [email protected]> > > 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 < > [email protected] > > > > > > > > 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 < > > [email protected]> > > > > > > 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 > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > To unsubscribe, e-mail: > [email protected] > > > > > > > > > > > For additional commands, e-mail: > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Elliotte Rusty Harold > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Elliotte Rusty Harold > > [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
