Le lun. 2 août 2021 à 17:23, Robert Scholte <rfscho...@apache.org> a écrit :
> Thinks to keep in mind when trying to log for a specific execution of a > plugin: > - loggers use the classname as identifier, so you need to know when to the > execution starts and ends. > - plugins can call Maven Core code, most likely you want this to be logged > as part of the plugin execution. > - multithreading... need I say more? > > Most of the time you're only interested in logging of the last failed > plugin of the previous build, but it is very very tricky to implement. > Don't think so, it is very common a plugin execution depends on another plugin execution so you need both. This is why I think it is sane to have --log-level [INFO|DEBUG|....] (whatever the name is) as a starting logging config and not --log-info <fqn> which will likely miss what is needed. side note: threading already supports to log the thread the log comes from so I guess it is sufficient for such a feature, anything more fancy can be misleading on CI where you can't rely on local debugging when logs are weird/hard to read. There are always cases you can't log properly but for end users it is saner to say "I want to log at level L" rather than "I want the build to be verbose" or "I want the build to be quiet" which looks like it depends which plugin rely on a maven toggle. So in case we want a breaking change in log level CLI options, the log level switch is saner no? So overall idea is to never try to be more clever than our API enables and stick to the minimal logging binding configuration we control well and finally drop the old CLI opts related to the log level in favor of the more aligned one. For more advanced use cases, the user can rely on .mvn/jvm.config to fully tune the slf4j binding we provide (or equivalent xml/yaml/json config file if the binding accepts it). Once again (if it is ambiguous), I'm also happy with a status quo (ie no change compared to maven 3) if it sounds better for everyone. > > Robert > On 2-8-2021 16:06:06, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Le lun. 2 août 2021 à 16:02, Michael Osipov a écrit : > > > Am 2021-08-02 um 09:39 schrieb Romain Manni-Bucau: > > > Le dim. 1 août 2021 à 22:37, Michael Osipov a > > écrit : > > > > > >> A prerequisite PR is ready: https://github.com/apache/maven/pull/519 > > > > > > > > > Maybe I'm a bit "off" on this one but shouldn't we just enable to > > configure > > > slf4j from the command line with "shortcuts"? ie --info --debug > > > --org.apache.wagon-debug > > > > > > Once you know all go through a logger it does not make much sense to > > have a > > > verbose toggle anymore IMHO and it is not powerful enough to enable > what > > > you need (even the JVM uses system properties to filter the logs you > > wants > > > so can be saner to rely on slf4j for us?) > > > > It is a bit problematic. SLF4J does not log so you need to delegate to > > the actual logging implementation. I would prefer --log-level/-L {level} > > or {logger}:{level}. -L can be provided multiple times. > > There are open tickets requesting this, but no one has provided a > > concept how to solve this for all supported logging bindings. > > > > Guess only for the built-in binding is sufficient - if you change the > binding you can want to ensure it is integrated anyway since other things > can not work properly like log4j2/logback bindings require some flushing to > work properly for ex so it is not only a switch. > That said, the point is to not make --debug specific. An interesting > question about it do we need quiet then? > > Think, if we break anything (+-0 on that), it is where we should go rather > than renaming anything which means breaking end users for no feature for > them (which is always a bad idea IMHO). > > > > > > M > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
