Le dim. 3 mars 2024 à 22:28, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2024-03-03 à 20 h 38, Romain Manni-Bucau a écrit : > > > the idea of maven-api was to abstract anything from the implementation > > to be able to change > A standard Java interface is as good as a Maven interface for that > purpose if they define equivalent methods, which is the case of > System.Logger versus Maven Log. > > > > if you use System.Logger you can't until you don't respect the > > contract which implies LoggerFinder is used which would be a > > misbehavior of the JVM for any user - and as overriding JUL it is used. > I'm not aware of any contract saying that System.Logger must be obtained > by System.getLogger(). The Javadoc only said "are typically obtained > from the System class". Users are not supposed to expect a particular > implementation. If the logger is provided by IOC (as it is in Maven), > users are not supposed to expect that the instance was fetched in any > particular way. > It is expected to use System so the logger finder. if it is not the case you broke the contract of this API. Indeed it works but the setup will be misbehaving: as an user you switch the backend and it is not used. > > > > So you mean reusing existing impl? this would be handled by maven > > bridge so not an issue to me, same as today there. > As said above, the purpose of an interface is to allow implementation to > change. I provided an example where switching to the standard > implementation would be useful for debugging purposes. The standards > implementations need to be invoked directly (not through a custom Log > interface) for providing useful "source class" and "source method" > information. That is the issue. I'm not sure what a "Maven bridge" is, > but if it is some kind of wrappers, this is an extra complexity which > need to be justified by extra features. In the current Maven Log > interface, there is no such extra features except slightly more compact > method calls (logging levels as method names instead of a method > parameter). > As a matter of fact it is current state so not sure what you want to enable. The extra complexity is justified by owning the implementation and ensuring its stability and behavior accross JDK and versions. It is the same rational than creating maven-api to not restate the 10 years of discussion leading to that. Using the JDK would have been an option, JUL had been proposed multiple times and just needs a thin layer - like tomcat one for ex to enable logging config per classrealm - but core committers always had been opposed to that and System.Logger has some limitations and would need the same glue anyway so guess Log will stay and we'll keep delegating until an user backend which supports or not these features (not saying I find our solution good but we were close to worse using slf4j directly which is out of our control, proven not stable enough and conflicts with mojo to make it even more explicit). > > > > I'm not sure what you plan to do but it is the same amount of work > > (normalized by the capacity of the API, indeed JUL has more API than > > current System.Logger). > I have no plan yet, only making a proposal based on what I saw in the > Maven compiler plugin. I agree that java.util.logging has more > capabilities and I would generally be in favour of switching to it (this > is what I use myself in my projects). However, in the particular case of > Maven, the situation is a little bit different because Maven uses the > Log interface sometime for logging, and sometime for console output. For > example, the Maven compiler plugin produces some messages saying "Using > XYZ" (this is logging), then a block of text representing the Mojo > execution result (success or failure) for the person who launched Maven > (this is console output). So in the way that it is used by Maven, Log is > not really a logger interface but rather a "println" facade which can > also, in some occasions, be a real logger. > Guess the mixture here is the one any plugin doing an exec (or similar like ToolProvider) has: how to forward the stdout/stderr to the logging system, often it is per line (and it makes sense to not hang and log everything at once) but has the pitfall to use the logger as a println. But it is a particular consumer usage, this is not what Log defines, it defines a real logger and some plugin use it as println cause it is what they need from my understanding. > > The proposal to use System.Logger is just that: continue to use it as a > "println" facade as Maven currently does, but with the added capability > to switch to a useful logger when needed (e.g. for debugging). > Ok, assume we do nothing, we reached that stage sine ~10 years - ok the way to do it changed a bit but we didn't loose it, this is where you lost me. > > Martin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
