Re: Logging in Maven 4

[Romain Manni-Bucau]

Le lun. 4 mars 2024 à 10:49, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Note: this logging issue is not very important. If there is such
> resistance against it, I will not insist.
>
>
> Le 2024-03-04 à 08 h 35, Romain Manni-Bucau a écrit :
>
> > Please read
> >
> https://docs.oracle.com/javase%2F9%2Fdocs%2Fapi%2F%2F/java/lang/System.LoggerFinder.html
> I have already read that. The idea that System.Logger instance MUST be
> obtained thought a LoggerFinder is your own interpretation not backed by
> any statement in the Javadoc. For me, it is as valid as saying that
> Java.nio.file.Path instances MUST be obtained by calls to Path.of(...),
> that java.io.PrintStream instances MUST be System.out or System.err,
> etc. If I'm wrong, please point us to the exact sentence in the contract.
>

As any interface you can also change it - and trust me I'm one of those who
did it a lot ;) - but it is also always misleading to end user to get an
instance which does not come from the expected factory if this one has a
standard and here it is the finder.
So technically feasible but I'm not convinced it would be sane for end user
and, again, the point is that it does not help on the topic.


>
>
> > "But System.Logger is the same compromise and is as suitable as Log."
> > this is nonsense to me since it is strictly equivalent in terms of API
> > but not in terms of maven guarantee and stability for plugin writers"
> Please elaborate: why a Maven interface would provide more stability
> guarantees than a standard Java interface in which all methods are
> equivalent? A reason other than claiming that using a System.Logger
> instance not provided by LoggerFinder would break applications, unless
> you can demonstrate that.
>
>
> > "However, there is nothing in System.Logger, System.getLogger() or
> > System.LoggerFinder javadoc saying that we should not use it." - cause
> > you don't care about the issue maven api solves for now.
> What are the issues that Maven API solves that an equivalent standard
> interface does not solve? "Stability" is vague. Can you give an example?
>

Being maven owned and abstracted from a standard which moves.
We can make log contextual whereas if we implement the standard we need
to...implement it, any method, any version.
This just does not work, the famous slf4j standard beat us already and JVM
makes its API evolving so it can break us any time, check out Stream usage
in CDI (Instance) for an example.
So we need a maven owned abstraction.


>
>
> > Also "Maven, which need more than println but not as much as a real
> > logging framework" is wrong, this is only the local case for a subset
> > of plugins, anything else needs a real logging system and mvnd too.
> Okay. But it can be a two steps process. First use the standard
> interface when it fits the exact same purpose than the Maven interface,
> and later separate "logging" from "console output".
>

Hmm, I don't see much issue there, for me whatever we do we'll end up in
current state more or less cause it is the need even if not as neat as we
all would like and splitting would be worse cause mix the API and make it
even more complicated for consumers so not sure I'm keen to have 2 API.
Maybe a stream redirector to the logging API in a shared module can help
but will end in the same layers IMHO.


>
>
> > @Pavel: exactly cause the API is only a part of the solution, the
> > lifecycle is another one and there System.Logger fills another gap the
> > JVM had and was using System.out before as explained in the first
> > responses.
> The fact that System.Logger fills a gap does not mean that it is not
> intended to be used for any other purpose. The LoggerFinder javadoc
> mentions "Libraries and classes that only need loggers". The fact that
> the interface was added in `java.lang` package suggests that it is
> intended to be used. E.g., it is a way for libraries to keep the
> "java.logging" module optional.
>

Yes and not, it is literally a design constraint of the JVM from my window
cause it must be used for low level/bootstrap log so no real choice than
putting it in lang and opening it.
When it popped out a lot of backend tried to use it primarly but today it
is a dead topic, not sure there was a lot of pitfall except the fact it is
an api without backend but the main blocker for me would be the lifecycle
and fact we loose the guarantee of instrumentation kind of forcing people
to await for next release to upgrade which is something we don't impose as
of today and I think it is good to be able to adopt new jvm releases
faster, even if it sometimes needs some hack in dependencies, rather than
awaiting.

Indeed just my opinion but for me the ROI is > to keep our API.


>
> But anyway, as said before, this is not very important so I give up.
>
>  Martin
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, 

Re: Logging in Maven 4

[Martin Desruisseaux]

Note: this logging issue is not very important. If there is such 
resistance against it, I will not insist.



Le 2024-03-04 à 08 h 35, Romain Manni-Bucau a écrit :

Please read 
https://docs.oracle.com/javase%2F9%2Fdocs%2Fapi%2F%2F/java/lang/System.LoggerFinder.html
I have already read that. The idea that System.Logger instance MUST be 
obtained thought a LoggerFinder is your own interpretation not backed by 
any statement in the Javadoc. For me, it is as valid as saying that 
Java.nio.file.Path instances MUST be obtained by calls to Path.of(...), 
that java.io.PrintStream instances MUST be System.out or System.err, 
etc. If I'm wrong, please point us to the exact sentence in the contract.



"But System.Logger is the same compromise and is as suitable as Log." 
this is nonsense to me since it is strictly equivalent in terms of API 
but not in terms of maven guarantee and stability for plugin writers"
Please elaborate: why a Maven interface would provide more stability 
guarantees than a standard Java interface in which all methods are 
equivalent? A reason other than claiming that using a System.Logger 
instance not provided by LoggerFinder would break applications, unless 
you can demonstrate that.



"However, there is nothing in System.Logger, System.getLogger() or 
System.LoggerFinder javadoc saying that we should not use it." - cause 
you don't care about the issue maven api solves for now.
What are the issues that Maven API solves that an equivalent standard 
interface does not solve? "Stability" is vague. Can you give an example?



Also "Maven, which need more than println but not as much as a real 
logging framework" is wrong, this is only the local case for a subset 
of plugins, anything else needs a real logging system and mvnd too.
Okay. But it can be a two steps process. First use the standard 
interface when it fits the exact same purpose than the Maven interface, 
and later separate "logging" from "console output".



@Pavel: exactly cause the API is only a part of the solution, the 
lifecycle is another one and there System.Logger fills another gap the 
JVM had and was using System.out before as explained in the first 
responses. 
The fact that System.Logger fills a gap does not mean that it is not 
intended to be used for any other purpose. The LoggerFinder javadoc 
mentions "Libraries and classes that only need loggers". The fact that 
the interface was added in `java.lang` package suggests that it is 
intended to be used. E.g., it is a way for libraries to keep the 
"java.logging" module optional.


But anyway, as said before, this is not very important so I give up.

    Martin



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Logging in Maven 4

[Romain Manni-Bucau]

Martin

Please read
https://docs.oracle.com/javase%2F9%2Fdocs%2Fapi%2F%2F/java/lang/System.LoggerFinder.html

And "For the third time" we already have it

Also please stop this kind of statement "But System.Logger is the same
compromise and is as suitable as Log." this is nonsense to me since it is
strictly equivalent in terms of API but not in terms of maven guarantee and
stability for plugin writers which is the only point to have our log API
and not reuse JUL.
Similarly "However, there is nothing in System.Logger, System.getLogger()
or System.LoggerFinder javadoc saying that we should not use it." - cause
you don't care about the issue maven api solves for now.
So there is no real way we do it, as I repeated 3 times, cause the key is
not the API.

Also "Maven, which need more than println but not as much as a real logging
framework" is wrong, this is only the local case for a subset of plugins,
anything else needs a real logging system and mvnd too.

Think you generalized too much compiler work you did but it is not the
maven generic case.

@Pavel: exactly cause the API is only a part of the solution, the lifecycle
is another one and there System.Logger fills another gap the JVM had and
was using System.out before as explained in the first responses.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 4 mars 2024 à 01:13, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2024-03-04 à 00 h 31, Pavel Horal a écrit :
> >
> > isn't System.Logger mainly for JDK internals? I always thought that
> > using it is in a similar ballpark as using java.util.Optional in
> > method arguments (i.e. „please don’t“).
> >
> System.Logger was needed by JDK internal, e.g. because of bootstrapping
> issues. Another reason is that java.logging is a separated JPMS module,
> so the java.base module cannot depend on it. However, there is nothing
> in System.Logger, System.getLogger() or System.LoggerFinder javadoc
> saying that we should not use it. If it was the case, I think that
> Oracle would not have placed those interfaces in public API, and
> certainly not in the java.lang package which is implicitly imported by
> everyone.
>
> System.Logger can be used by applications that want to keep the
> java.logging module optional. It is also a good fit for applications,
> like Maven, which need more than println but not as much as a real
> logging framework.
>
>  Martin
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Logging in Maven 4

[Martin Desruisseaux]

Le 2024-03-04 à 00 h 31, Pavel Horal a écrit :


isn't System.Logger mainly for JDK internals? I always thought that 
using it is in a similar ballpark as using java.util.Optional in 
method arguments (i.e. „please don’t“).


System.Logger was needed by JDK internal, e.g. because of bootstrapping 
issues. Another reason is that java.logging is a separated JPMS module, 
so the java.base module cannot depend on it. However, there is nothing 
in System.Logger, System.getLogger() or System.LoggerFinder javadoc 
saying that we should not use it. If it was the case, I think that 
Oracle would not have placed those interfaces in public API, and 
certainly not in the java.lang package which is implicitly imported by 
everyone.


System.Logger can be used by applications that want to keep the 
java.logging module optional. It is also a good fit for applications, 
like Maven, which need more than println but not as much as a real 
logging framework.


    Martin



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Logging in Maven 4

[Pavel Horal]

Hi,

sorry to jump into a conversation, but isn't System.Logger mainly for JDK
internals? I always thought that using it is in a similar ballpark as using
java.util.Optional in method arguments (i.e. „please don’t“).

Pavel

On Sun, 3 Mar 2024 at 23:54, Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Le 2024-03-03 à 22 h 53, Romain Manni-Bucau a écrit :
>
> > It is expected to use System so the logger finder. if it is not the
> > case you broke the contract of this API.
> >
> Can you point to the contract saying that?
>
>
> > As a matter of fact it is current state so not sure what you want to
> > enable.
> >
> For the third time: more useful log information ("real" source class and
> source method) when desired, e.g. for debugging.
>
>
> > It is the same rational than creating maven-api to not restate the 10
> > years of discussion leading to that.
> >
> I'm not questioning the whole Maven API, only a part that does not seem
> to have any added value compared to a standard Java interface that did
> not existed 10 years ago.
>
>
> > JUL had been proposed multiple times (…snip…) but core committers
> > always had been opposed to that and System.Logger has some limitations
> >
> Okay, so Log was the compromise between java.util.logging and println. I
> understand that. But System.Logger is the same compromise and is as
> suitable as Log. Its only drawback compared to Log was to not be
> available before Java 9.
>
>
> > 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.
> >
> I'm just proposing to replace Log by System.Logger, which provides the
> exact same API in only a slightly different way. So:
>
> logger.info("My information");
>
> Become:
>
> logger.log(System.Logger.Leven.INFO, "My information");
>
> That's all. The benefit is the one that I repeated 3 times. Part of my
> discussion in previous email was an attempt to justify that the extra
> verbosity caused by having to write "System.Logger.Leven.INFO" is not
> necessarily a bad thing if it creates an incentive to not invoke "log"
> for every line in multi-line messages.
>
>  Martin
>
>

Re: Logging in Maven 4

[Martin Desruisseaux]

Le 2024-03-03 à 22 h 53, Romain Manni-Bucau a écrit :

It is expected to use System so the logger finder. if it is not the 
case you broke the contract of this API.



Can you point to the contract saying that?


As a matter of fact it is current state so not sure what you want to 
enable.


For the third time: more useful log information ("real" source class and 
source method) when desired, e.g. for debugging.



It is the same rational than creating maven-api to not restate the 10 
years of discussion leading to that.


I'm not questioning the whole Maven API, only a part that does not seem 
to have any added value compared to a standard Java interface that did 
not existed 10 years ago.



JUL had been proposed multiple times (…snip…) but core committers 
always had been opposed to that and System.Logger has some limitations


Okay, so Log was the compromise between java.util.logging and println. I 
understand that. But System.Logger is the same compromise and is as 
suitable as Log. Its only drawback compared to Log was to not be 
available before Java 9.



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.


I'm just proposing to replace Log by System.Logger, which provides the 
exact same API in only a slightly different way. So:


   logger.info("My information");

Become:

   logger.log(System.Logger.Leven.INFO, "My information");

That's all. The benefit is the one that I repeated 3 times. Part of my 
discussion in previous email was an attempt to justify that the extra 
verbosity caused by having to write "System.Logger.Leven.INFO" is not 
necessarily a bad thing if it creates an incentive to not invoke "log" 
for every line in multi-line messages.


    Martin

Re: Logging in Maven 4

[Romain Manni-Bucau]

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: 

Re: Logging in Maven 4

[Martin Desruisseaux]

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.



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).



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.


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).


    Martin



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Logging in Maven 4

[Romain Manni-Bucau]

Le dim. 3 mars 2024 à 19:18, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2024-03-03 à 18 h 48, Romain Manni-Bucau a écrit :
>
> >> (snip) Nothing force us to use System.getLogger() for getting an
> >> instance of that interface. (snip)
> >>
> > Yes but you make something well specified misbehaving so while
> > technically true I think it would deserve us on the long run.
> >
> I do not understand this argument. The proposal is to replace a custom
> interface by a standard one doing the same thing. How to get an instance
> of that interface does not need to change. This is currently done that
> way in Maven Mojos:
>
> @Inject
> protected Log logger
>
> It would stay as before, except that Log would become System.Logger.
> Where do you see a misbehaviour?
>

Ok, then the idea of maven-api was to abstract anything from the
implementation to be able to change, as you can see 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 did not talked about performance, but about misleading information
> >> filled in log record (snip).
> >
> > For me it means a bug in the implementation
> >
> It is not a bug. When a logger uses stackwalker for determining who is
> logging, it stops at the first stack frame which is not a method
> internal to the logger implementation. It has no way to know that it
> should continue a few more frames further. There is no API for saying
> "please ignore stack frames that are inside the Maven Log class".
>

So you mean reusing existing impl? this would be handled by maven bridge so
not an issue to me, same as today there.


>
> When using java.util.logging, we can override the automatic detection by
> our own. But this is more work, e.g. we have to replace all calls to a
> Logger.log(…) method by a call to our custom method which will override
> the LogRecord default values. However 1) we cannot do that with
> System.Logger, and 2) we don't need this complication at all if we just
> use the logger directly, without passing through a Maven custom interface.
>

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).
Long story short it is a matter of using
https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/common/logging/AbstractDelegatingLogger.java
.


>
>
> > So overall I'm not sure the goal,
> >
> For example when Maven is run with the --debug flag, it could use the
> logger provided by System.getLogger() instead of the Maven default
> "println-like" logger. We may lost coloration, but each log message
> would be preceded by a line telling which method in which class emitted
> that log. This is very useful when there is no exception stack trace but
> we still want to look in the code what is going on.
>

Hmm, I see so you mean if we change everything we could get the same than
what we have today?
You can already switch slf4j binding - I use JUL for ex but logback is
another common one - and get these info.

So if it is your goal I guess we can work on the documentation only?


>
>  Martin
>
>

Re: Logging in Maven 4

[Martin Desruisseaux]

Le 2024-03-03 à 18 h 48, Romain Manni-Bucau a écrit :

(snip) Nothing force us to use System.getLogger() for getting an 
instance of that interface. (snip)


Yes but you make something well specified misbehaving so while 
technically true I think it would deserve us on the long run.


I do not understand this argument. The proposal is to replace a custom 
interface by a standard one doing the same thing. How to get an instance 
of that interface does not need to change. This is currently done that 
way in Maven Mojos:


   @Inject
   protected Log logger

It would stay as before, except that Log would become System.Logger. 
Where do you see a misbehaviour?



I did not talked about performance, but about misleading information 
filled in log record (snip). 


For me it means a bug in the implementation

It is not a bug. When a logger uses stackwalker for determining who is 
logging, it stops at the first stack frame which is not a method 
internal to the logger implementation. It has no way to know that it 
should continue a few more frames further. There is no API for saying 
"please ignore stack frames that are inside the Maven Log class".


When using java.util.logging, we can override the automatic detection by 
our own. But this is more work, e.g. we have to replace all calls to a 
Logger.log(…) method by a call to our custom method which will override 
the LogRecord default values. However 1) we cannot do that with 
System.Logger, and 2) we don't need this complication at all if we just 
use the logger directly, without passing through a Maven custom interface.




So overall I'm not sure the goal,

For example when Maven is run with the --debug flag, it could use the 
logger provided by System.getLogger() instead of the Maven default 
"println-like" logger. We may lost coloration, but each log message 
would be preceded by a line telling which method in which class emitted 
that log. This is very useful when there is no exception stack trace but 
we still want to look in the code what is going on.


    Martin

Re: Logging in Maven 4

[Romain Manni-Bucau]

Le dim. 3 mars 2024 à 17:50, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Hello Romain
>
> Le 2024-03-03 à 17 h 02, Romain Manni-Bucau a écrit :
>
> > SystemLogger has the ServiceLoader "pick random first" implementation
> > which is not what we want
> >
> You are describing the behavior of the System.getLogger() method. I was
> talking about the use of the System.Logger interface. Nothing force us
> to use System.getLogger() for getting an instance of that interface. The
> flexibility is the same as before, except that it become possible to use
> System.getLogger() if desired.
>


Yes but you make something well specified misbehaving so while technically
true I think it would deserve us on the long run.


>
>
> > If we want to drop Log we would rather go to JUL, which stays more
> > powerful in terms of API, usable in terms of implementation and still
> > as pluggable as SystemLogger for a runtime like maven.
> >
> Yes, I also prefer java.util.logging. I proposed System.Logger because
> it has a one-to-one match with the current Maven Log (except in the way
> to specify the logging level). It is also less work for creating a
> custom implementation, which is apparently what Maven wants (it
> basically uses logger as a "println" functionality).
>

JUL is quite easy - very easy now we have stackwalker ;) - so I don't think
it would have been a blocker by itself.


>
>
> > The point about performance is kind of behind now we are java 17 we
> > have stackwalker so an integration thing but no more the old new
> > Throwable().getStackTrace() blocker.
> >
> I did not talked about performance, but about misleading information
> filled in log record. No matter if using stackwalker of exception trace,
> is System.Logger or java.util.logging are not used directly in the code,
> by default the source class name and source method name reported in the
> log record will be the class name / method name of the wrapper (for
> example Maven Log class) instead of the name of the place where the log
> occurred. We can fix that with java.util.logging at the cost of some
> effort, but not with System.Logger (as far as I know).
>

For me it means a bug in the implementation so no more an issue than doing
a logger.severe instead of info in mavenLog.info.
So maybe not a blocker?


>
>
> > I tend to agree with your point about N records (N>1) vs 1 record but
> > this is independent of all log API you mentionned.
> >
> I did not said that we need to change the log API for doing that, but
> that the fact that the use of System.Logger is more tedious (because of
> the way to specify logging level) may not be a bad thing, because it can
> be an incentive to fix that.
>

Ok but this is not linked to a specific logger AFAIK.


So overall I'm not sure the goal, replace slf4j? (if so i would support you
;))


>
>  Martin
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Logging in Maven 4

[Martin Desruisseaux]

Hello Romain

Le 2024-03-03 à 17 h 02, Romain Manni-Bucau a écrit :

SystemLogger has the ServiceLoader "pick random first" implementation 
which is not what we want


You are describing the behavior of the System.getLogger() method. I was 
talking about the use of the System.Logger interface. Nothing force us 
to use System.getLogger() for getting an instance of that interface. The 
flexibility is the same as before, except that it become possible to use 
System.getLogger() if desired.



If we want to drop Log we would rather go to JUL, which stays more 
powerful in terms of API, usable in terms of implementation and still 
as pluggable as SystemLogger for a runtime like maven.


Yes, I also prefer java.util.logging. I proposed System.Logger because 
it has a one-to-one match with the current Maven Log (except in the way 
to specify the logging level). It is also less work for creating a 
custom implementation, which is apparently what Maven wants (it 
basically uses logger as a "println" functionality).



The point about performance is kind of behind now we are java 17 we 
have stackwalker so an integration thing but no more the old new 
Throwable().getStackTrace() blocker.


I did not talked about performance, but about misleading information 
filled in log record. No matter if using stackwalker of exception trace, 
is System.Logger or java.util.logging are not used directly in the code, 
by default the source class name and source method name reported in the 
log record will be the class name / method name of the wrapper (for 
example Maven Log class) instead of the name of the place where the log 
occurred. We can fix that with java.util.logging at the cost of some 
effort, but not with System.Logger (as far as I know).



I tend to agree with your point about N records (N>1) vs 1 record but 
this is independent of all log API you mentionned.


I did not said that we need to change the log API for doing that, but 
that the fact that the use of System.Logger is more tedious (because of 
the way to specify logging level) may not be a bad thing, because it can 
be an incentive to fix that.


    Martin



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Logging in Maven 4

[Romain Manni-Bucau]

Hi,

I'm not sure I got what we would gain but here is my view on this topic:

* SystemLogger has the ServiceLoader "pick random first" implementation
which is not what we want I think and the API stays low level,
* If we want to drop Log we would rather go to JUL, which stays more
powerful in terms of API, usable in terms of implementation and stillas
pluggable as SystemLogger for a runtime like maven,
* The point about performance is kind of behind now we are java 17 we have
stackwalker so an integration thing but no more the old new
Throwable().getStackTrace() blocker,
* I tend to agree with your point about N records (N>1) vs 1 record but
this is independent of all log API you mentionned, we can fix it with maven
old log api, the new one, java or anything, it is a caller thing - but more
than agree we should stop logging lines but think records.

Guess I got your mail right and didn't interpret the multiple points I
understood.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 3 mars 2024 à 15:59, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Maven 4 defines a new interface, `org.apache.maven.api.plugin.Log`, with
> the usual debug(…), info(…), warn(…) and error(…) methods in it. Should
> we replace that by `java.lang.System.Logger`? (now possible with Java
> 17) The latter is also an interface, so we have the same flexibility for
> customization. The only drawback I could see is that codes such as
> `logger.info("something")` would become
> `logger.log(System.Logger.Level.INFO, "something")`, which is more
> tedious to write. However, this inconvenience may actually be a good
> thing (see below).
>
> We could keep the Maven `Log` interface as a wrapper around
> `System.Logger` for convenience. However, some logging implementations
> such as `java.util.logging` use Java reflection for detecting the caller
> class and method. If we keep the Maven `Log` as a convenience instead of
> direct use of `System.Logger`, I suspect that some logging systems will
> think that all logs always come from `org.apache.maven.api.plugin.Log`.
> This automatic detection is the reason why I propose a complete
> replacement.
>
> The current logger is used by Maven like below:
>
>
> getLog().info("-");
> getLog().error("COMPILATION ERROR : ");
>
> getLog().info("-");
> getLog().info(something);
>
> getLog().info("-");
>
> For most logging systems, the above is 5 log records, while actually
> there is only 1 log record and the rest is formatting. The fact that
> System.Logger is more verbose to use may encourage a better pattern like
> below, which results in a single log record:
>
> getLog().log(System.Logger.Level.ERROR,
>  """
>  -
>  COMPILATION ERROR :
>  -
>  """
>  + something +
>  """
>  -
>  """);
>
> The previous code snippet was mixing info(…) and error(…) maybe for
> coloration. But I see that Maven 4 has a MessageBuilder interface for
> this task, so the log record could be rewritten again like below:
>
> MessageBuilder mb = messageBuilderFactory.builder()
>
>  
> .info("-").newLine()
>  .error("COMPILATION ERROR : ").newLine()
>
>  
> .info("-").newLine()
>  .info(something).newLine()
>
>  
> .info("-").newLine();
> getLog().log(System.Logger.Level.ERROR, md.build());
>
> Any opinion?
>
>  Martin
>
>