subject:"Logging"

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 <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


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


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

2024-03-03 Thread 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


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

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,

Re: Logging in Maven 4


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

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


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

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


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

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 <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


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

Logging in Maven 4

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

Re: And while I'm on the subject of logging

2023-02-24 Thread Romain Manni-Bucau

Le ven. 24 févr. 2023 à 17:31, Delany  a écrit :

> I turned on -e as default last month and had to turn it off again.
> When a change causes a group of tests to fail I get the stack trace for
> each test failure first up in the project and then repeated as the cause of
> the reactor failing.
> I don't mind it on by default, but then how do I turn it off?
>

guess it needs --no-errors flag but since we switch the behavior in next
major it is highly possible to change the flag IMHO


>
> Another point is that if you can't easily rebuild with -e on to replicate
> your problem you've got a bigger problem than lots of log output.
>

Agree, this is why a minimum of external interactions (typically downloads)
is required IMHO, otherwise really hard to see what happens.


> Delany
>
> On Fri, 24 Feb 2023 at 15:15, Romain Manni-Bucau 
> wrote:
>
> > Hi Elliotte,
> >
> > I agree -e should be the default, I don't see the point to not have the
> > error cause when it fails.
> > Your point 2 is only relevant if you never built the project nor a
> project
> > with the same dependencies so I guess we can assume it is a corner case
> - I
> > was also often checkouting projects and having to download their deps but
> > it never had been an issue and actually was good to see what it uses
> > without opening all the project build files IMHO so really a taste/corner
> > case point.
> > So at the end the aggregation report Guillaume proposed and switch -e by
> > default on mvn 4 sounds like good options, no?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 24 févr. 2023 à 13:33, Kemal Soysal <
> > kemal.soy...@ls-it-solutions.de>
> > a écrit :
> >
> > > Hi Elliot,
> > >
> > > did you try to use mvnDebug?
> > >
> > > > Am 24.02.2023 um 13:26 schrieb Elliotte Rusty Harold <
> > elh...@ibiblio.org
> > > >:
> > > >
> > > > Real world example from the non-Apache project built with Maven I'm
> > > > working on this morning.
> > > >
> > > > 1. Build fails
> > > > 2. 591 lines of log output in my console, almost all of which are
> > > > artifacts being downloaded.
> > > > 3. Relevant lines: 1
> > > > 4. Percentage useful content: .17%
> > > >
> > > > That's bad. But wait. It gets worse.
> > > >
> > > > The only useful output is
> > > >
> > > > [ERROR] Failed to execute goal XXX (default) on project XXX:
> Execution
> > > > default of goal XXX failed.: NullPointerException -> [Help 1]
> > > >
> > > > So somewhere in my code (I'm writing the plugin that failed) there's
> a
> > > > NullPointerException. Where? The logs don't tell me! There's no stack
> > > > trace. There's no line number. The most critical information I need
> to
> > > > debug this isn't included by default. Of course,
> > > >
> > > > [ERROR] To see the full stack trace of the errors, re-run Maven with
> > > > the -e switch.
> > > >
> > > > So I rerun with -e and there's the info I need. But
> > > >
> > > > 1. I shouldn't have had to rerun. The information I actually needed
> > > > should have been shown to me up front.
> > > > 2. I shouldn't have been bombarded with 590 lines of irrelevant log
> > junk.
> > > >
> > > > Is anyone really willing to argue that the list of artifacts Maven
> > > > downloaded and the amount of time each took are somehow more likely
> to
> > > > be relevant than an exception arising in the developer's own code?
> And
> > > > yet that is exactly what we're doing.
> > > >
> > > > On Mon, Feb 20, 2023 at 9:33 AM Elliotte Rusty Harold
> > > >  wrote:
> > > >>
> > > >> Typical log message in build:
> > > >>
> > > >> Downloaded from central:
> > > >>
> > >
> >
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> > > >> (14 kB at 776 kB/s)
> > > >>
> > > >> I have never, ever needed or wanted to know how fast a single
> artifact
> > > >> was downloaded. And in the extremely unlikely event  I cared how big
> > > >> it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB
> at
> > > >> 776 kB/s)?
> > > >>
> > > >> Maven log files today are often multiple megabytes. Many continuous
> > > >> integration Web UIs truncate them to a 1 MB or so. Any unread info
> we
> > > >> can remove to bring the size down is helpful, and also makes it much
> > > >> easier for devs to find the lines they actually care about.
> > > >>
> > > >> --
> > > >> Elliotte Rusty Harold
> > > >> elh...@ibiblio.org
> > > >
> > > >
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > elh...@ibiblio.org
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands,

Re: And while I'm on the subject of logging

2023-02-24 Thread Delany

I turned on -e as default last month and had to turn it off again.
When a change causes a group of tests to fail I get the stack trace for
each test failure first up in the project and then repeated as the cause of
the reactor failing.
I don't mind it on by default, but then how do I turn it off?

Another point is that if you can't easily rebuild with -e on to replicate
your problem you've got a bigger problem than lots of log output.
Delany

On Fri, 24 Feb 2023 at 15:15, Romain Manni-Bucau 
wrote:

> Hi Elliotte,
>
> I agree -e should be the default, I don't see the point to not have the
> error cause when it fails.
> Your point 2 is only relevant if you never built the project nor a project
> with the same dependencies so I guess we can assume it is a corner case - I
> was also often checkouting projects and having to download their deps but
> it never had been an issue and actually was good to see what it uses
> without opening all the project build files IMHO so really a taste/corner
> case point.
> So at the end the aggregation report Guillaume proposed and switch -e by
> default on mvn 4 sounds like good options, no?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 24 févr. 2023 à 13:33, Kemal Soysal <
> kemal.soy...@ls-it-solutions.de>
> a écrit :
>
> > Hi Elliot,
> >
> > did you try to use mvnDebug?
> >
> > > Am 24.02.2023 um 13:26 schrieb Elliotte Rusty Harold <
> elh...@ibiblio.org
> > >:
> > >
> > > Real world example from the non-Apache project built with Maven I'm
> > > working on this morning.
> > >
> > > 1. Build fails
> > > 2. 591 lines of log output in my console, almost all of which are
> > > artifacts being downloaded.
> > > 3. Relevant lines: 1
> > > 4. Percentage useful content: .17%
> > >
> > > That's bad. But wait. It gets worse.
> > >
> > > The only useful output is
> > >
> > > [ERROR] Failed to execute goal XXX (default) on project XXX: Execution
> > > default of goal XXX failed.: NullPointerException -> [Help 1]
> > >
> > > So somewhere in my code (I'm writing the plugin that failed) there's a
> > > NullPointerException. Where? The logs don't tell me! There's no stack
> > > trace. There's no line number. The most critical information I need to
> > > debug this isn't included by default. Of course,
> > >
> > > [ERROR] To see the full stack trace of the errors, re-run Maven with
> > > the -e switch.
> > >
> > > So I rerun with -e and there's the info I need. But
> > >
> > > 1. I shouldn't have had to rerun. The information I actually needed
> > > should have been shown to me up front.
> > > 2. I shouldn't have been bombarded with 590 lines of irrelevant log
> junk.
> > >
> > > Is anyone really willing to argue that the list of artifacts Maven
> > > downloaded and the amount of time each took are somehow more likely to
> > > be relevant than an exception arising in the developer's own code? And
> > > yet that is exactly what we're doing.
> > >
> > > On Mon, Feb 20, 2023 at 9:33 AM Elliotte Rusty Harold
> > >  wrote:
> > >>
> > >> Typical log message in build:
> > >>
> > >> Downloaded from central:
> > >>
> >
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> > >> (14 kB at 776 kB/s)
> > >>
> > >> I have never, ever needed or wanted to know how fast a single artifact
> > >> was downloaded. And in the extremely unlikely event  I cared how big
> > >> it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
> > >> 776 kB/s)?
> > >>
> > >> Maven log files today are often multiple megabytes. Many continuous
> > >> integration Web UIs truncate them to a 1 MB or so. Any unread info we
> > >> can remove to bring the size down is helpful, and also makes it much
> > >> easier for devs to find the lines they actually care about.
> > >>
> > >> --
> > >> Elliotte Rusty Harold
> > >> elh...@ibiblio.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
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: And while I'm on the subject of logging

2023-02-24 Thread Xeno Amess

+1 for -e default

From: Romain Manni-Bucau 
Sent: Friday, February 24, 2023 9:15:15 PM
To: Maven Developers List 
Subject: Re: And while I'm on the subject of logging

Hi Elliotte,

I agree -e should be the default, I don't see the point to not have the
error cause when it fails.
Your point 2 is only relevant if you never built the project nor a project
with the same dependencies so I guess we can assume it is a corner case - I
was also often checkouting projects and having to download their deps but
it never had been an issue and actually was good to see what it uses
without opening all the project build files IMHO so really a taste/corner
case point.
So at the end the aggregation report Guillaume proposed and switch -e by
default on mvn 4 sounds like good options, no?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 24 févr. 2023 à 13:33, Kemal Soysal 
a écrit :

> Hi Elliot,
>
> did you try to use mvnDebug?
>
> > Am 24.02.2023 um 13:26 schrieb Elliotte Rusty Harold  >:
> >
> > Real world example from the non-Apache project built with Maven I'm
> > working on this morning.
> >
> > 1. Build fails
> > 2. 591 lines of log output in my console, almost all of which are
> > artifacts being downloaded.
> > 3. Relevant lines: 1
> > 4. Percentage useful content: .17%
> >
> > That's bad. But wait. It gets worse.
> >
> > The only useful output is
> >
> > [ERROR] Failed to execute goal XXX (default) on project XXX: Execution
> > default of goal XXX failed.: NullPointerException -> [Help 1]
> >
> > So somewhere in my code (I'm writing the plugin that failed) there's a
> > NullPointerException. Where? The logs don't tell me! There's no stack
> > trace. There's no line number. The most critical information I need to
> > debug this isn't included by default. Of course,
> >
> > [ERROR] To see the full stack trace of the errors, re-run Maven with
> > the -e switch.
> >
> > So I rerun with -e and there's the info I need. But
> >
> > 1. I shouldn't have had to rerun. The information I actually needed
> > should have been shown to me up front.
> > 2. I shouldn't have been bombarded with 590 lines of irrelevant log junk.
> >
> > Is anyone really willing to argue that the list of artifacts Maven
> > downloaded and the amount of time each took are somehow more likely to
> > be relevant than an exception arising in the developer's own code? And
> > yet that is exactly what we're doing.
> >
> > On Mon, Feb 20, 2023 at 9:33 AM Elliotte Rusty Harold
> >  wrote:
> >>
> >> Typical log message in build:
> >>
> >> Downloaded from central:
> >>
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >> (14 kB at 776 kB/s)
> >>
> >> I have never, ever needed or wanted to know how fast a single artifact
> >> was downloaded. And in the extremely unlikely event  I cared how big
> >> it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
> >> 776 kB/s)?
> >>
> >> Maven log files today are often multiple megabytes. Many continuous
> >> integration Web UIs truncate them to a 1 MB or so. Any unread info we
> >> can remove to bring the size down is helpful, and also makes it much
> >> easier for devs to find the lines they actually care about.
> >>
> >> --
> >> Elliotte Rusty Harold
> >> elh...@ibiblio.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
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: And while I'm on the subject of logging

2023-02-24 Thread Romain Manni-Bucau

Hi Elliotte,

I agree -e should be the default, I don't see the point to not have the
error cause when it fails.
Your point 2 is only relevant if you never built the project nor a project
with the same dependencies so I guess we can assume it is a corner case - I
was also often checkouting projects and having to download their deps but
it never had been an issue and actually was good to see what it uses
without opening all the project build files IMHO so really a taste/corner
case point.
So at the end the aggregation report Guillaume proposed and switch -e by
default on mvn 4 sounds like good options, no?

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



Le ven. 24 févr. 2023 à 13:33, Kemal Soysal 
a écrit :

> Hi Elliot,
>
> did you try to use mvnDebug?
>
> > Am 24.02.2023 um 13:26 schrieb Elliotte Rusty Harold  >:
> >
> > Real world example from the non-Apache project built with Maven I'm
> > working on this morning.
> >
> > 1. Build fails
> > 2. 591 lines of log output in my console, almost all of which are
> > artifacts being downloaded.
> > 3. Relevant lines: 1
> > 4. Percentage useful content: .17%
> >
> > That's bad. But wait. It gets worse.
> >
> > The only useful output is
> >
> > [ERROR] Failed to execute goal XXX (default) on project XXX: Execution
> > default of goal XXX failed.: NullPointerException -> [Help 1]
> >
> > So somewhere in my code (I'm writing the plugin that failed) there's a
> > NullPointerException. Where? The logs don't tell me! There's no stack
> > trace. There's no line number. The most critical information I need to
> > debug this isn't included by default. Of course,
> >
> > [ERROR] To see the full stack trace of the errors, re-run Maven with
> > the -e switch.
> >
> > So I rerun with -e and there's the info I need. But
> >
> > 1. I shouldn't have had to rerun. The information I actually needed
> > should have been shown to me up front.
> > 2. I shouldn't have been bombarded with 590 lines of irrelevant log junk.
> >
> > Is anyone really willing to argue that the list of artifacts Maven
> > downloaded and the amount of time each took are somehow more likely to
> > be relevant than an exception arising in the developer's own code? And
> > yet that is exactly what we're doing.
> >
> > On Mon, Feb 20, 2023 at 9:33 AM Elliotte Rusty Harold
> >  wrote:
> >>
> >> Typical log message in build:
> >>
> >> Downloaded from central:
> >>
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >> (14 kB at 776 kB/s)
> >>
> >> I have never, ever needed or wanted to know how fast a single artifact
> >> was downloaded. And in the extremely unlikely event  I cared how big
> >> it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
> >> 776 kB/s)?
> >>
> >> Maven log files today are often multiple megabytes. Many continuous
> >> integration Web UIs truncate them to a 1 MB or so. Any unread info we
> >> can remove to bring the size down is helpful, and also makes it much
> >> easier for devs to find the lines they actually care about.
> >>
> >> --
> >> Elliotte Rusty Harold
> >> elh...@ibiblio.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
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: And while I'm on the subject of logging

2023-02-24 Thread Kemal Soysal

Hi Elliot,

did you try to use mvnDebug?

> Am 24.02.2023 um 13:26 schrieb Elliotte Rusty Harold :
> 
> Real world example from the non-Apache project built with Maven I'm
> working on this morning.
> 
> 1. Build fails
> 2. 591 lines of log output in my console, almost all of which are
> artifacts being downloaded.
> 3. Relevant lines: 1
> 4. Percentage useful content: .17%
> 
> That's bad. But wait. It gets worse.
> 
> The only useful output is
> 
> [ERROR] Failed to execute goal XXX (default) on project XXX: Execution
> default of goal XXX failed.: NullPointerException -> [Help 1]
> 
> So somewhere in my code (I'm writing the plugin that failed) there's a
> NullPointerException. Where? The logs don't tell me! There's no stack
> trace. There's no line number. The most critical information I need to
> debug this isn't included by default. Of course,
> 
> [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> 
> So I rerun with -e and there's the info I need. But
> 
> 1. I shouldn't have had to rerun. The information I actually needed
> should have been shown to me up front.
> 2. I shouldn't have been bombarded with 590 lines of irrelevant log junk.
> 
> Is anyone really willing to argue that the list of artifacts Maven
> downloaded and the amount of time each took are somehow more likely to
> be relevant than an exception arising in the developer's own code? And
> yet that is exactly what we're doing.
> 
> On Mon, Feb 20, 2023 at 9:33 AM Elliotte Rusty Harold
>  wrote:
>> 
>> Typical log message in build:
>> 
>> Downloaded from central:
>> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
>> (14 kB at 776 kB/s)
>> 
>> I have never, ever needed or wanted to know how fast a single artifact
>> was downloaded. And in the extremely unlikely event  I cared how big
>> it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
>> 776 kB/s)?
>> 
>> Maven log files today are often multiple megabytes. Many continuous
>> integration Web UIs truncate them to a 1 MB or so. Any unread info we
>> can remove to bring the size down is helpful, and also makes it much
>> easier for devs to find the lines they actually care about.
>> 
>> --
>> Elliotte Rusty Harold
>> elh...@ibiblio.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
> 



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

Re: And while I'm on the subject of logging

2023-02-24 Thread Elliotte Rusty Harold

Real world example from the non-Apache project built with Maven I'm
working on this morning.

1. Build fails
2. 591 lines of log output in my console, almost all of which are
artifacts being downloaded.
3. Relevant lines: 1
4. Percentage useful content: .17%

That's bad. But wait. It gets worse.

The only useful output is

[ERROR] Failed to execute goal XXX (default) on project XXX: Execution
default of goal XXX failed.: NullPointerException -> [Help 1]

So somewhere in my code (I'm writing the plugin that failed) there's a
NullPointerException. Where? The logs don't tell me! There's no stack
trace. There's no line number. The most critical information I need to
debug this isn't included by default. Of course,

[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.

So I rerun with -e and there's the info I need. But

1. I shouldn't have had to rerun. The information I actually needed
should have been shown to me up front.
2. I shouldn't have been bombarded with 590 lines of irrelevant log junk.

Is anyone really willing to argue that the list of artifacts Maven
downloaded and the amount of time each took are somehow more likely to
be relevant than an exception arising in the developer's own code? And
yet that is exactly what we're doing.

On Mon, Feb 20, 2023 at 9:33 AM Elliotte Rusty Harold
 wrote:
>
> Typical log message in build:
>
> Downloaded from central:
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> (14 kB at 776 kB/s)
>
> I have never, ever needed or wanted to know how fast a single artifact
> was downloaded. And in the extremely unlikely event  I cared how big
> it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
> 776 kB/s)?
>
> Maven log files today are often multiple megabytes. Many continuous
> integration Web UIs truncate them to a 1 MB or so. Any unread info we
> can remove to bring the size down is helpful, and also makes it much
> easier for devs to find the lines they actually care about.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.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

Re: And while I'm on the subject of logging

2023-02-23 Thread Delany

In the spirit of your elephant analogy, what is deserving of INFO level
logging?


On Thu, 23 Feb 2023 at 14:11, Elliotte Rusty Harold 
wrote:

> On Wed, Feb 22, 2023 at 11:51 AM Romain Manni-Bucau
>  wrote:
> >
> > Eliotte I kind of fail to follow your reasoning because it literally
> means
> > don't log any info and just set default log level to ERROR which I don't
> > think will make anyone happy.
>
> Thanks for saying this. I think I see the disconnect now. I'm saying
> log the errors and identify what's an error and what isn't. Artifact
> is 404? Log it. Artifact is slow? Log it. Artifact downloads just
> fine: don't log it. Don't hide the real problems in a sea of useless
> log junk.
>
> > You also tend to think everything works all the time but network issues
> are
> > not work/fail kind of issue, the hanging case is really bothering and
> > downloading logs really help there when you can keep them.
>
> Again, that is *NOT* what I am saying. I think that network issues are
> a real problem which is why I want them to be much easier to find and
> debug by not logging things that aren't problems.
>
> --
> 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
>
>

Re: And while I'm on the subject of logging

2023-02-23 Thread Romain Manni-Bucau

Hmm, I see but it also means you will hide the network issues because they
often are "you will not see anything".
Does it bother you so often? I mean, most of the time it is downloaded.
Is it just a snapshot thing? Maybe we can reduce the log only for snapshot
daily (whatever frequency) updates?


Le jeu. 23 févr. 2023 à 13:11, Elliotte Rusty Harold  a
écrit :

> On Wed, Feb 22, 2023 at 11:51 AM Romain Manni-Bucau
>  wrote:
> >
> > Eliotte I kind of fail to follow your reasoning because it literally
> means
> > don't log any info and just set default log level to ERROR which I don't
> > think will make anyone happy.
>
> Thanks for saying this. I think I see the disconnect now. I'm saying
> log the errors and identify what's an error and what isn't. Artifact
> is 404? Log it. Artifact is slow? Log it. Artifact downloads just
> fine: don't log it. Don't hide the real problems in a sea of useless
> log junk.
>
> > You also tend to think everything works all the time but network issues
> are
> > not work/fail kind of issue, the hanging case is really bothering and
> > downloading logs really help there when you can keep them.
>
> Again, that is *NOT* what I am saying. I think that network issues are
> a real problem which is why I want them to be much easier to find and
> debug by not logging things that aren't problems.
>
> --
> 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
>
>

Re: And while I'm on the subject of logging

2023-02-23 Thread Elliotte Rusty Harold

On Wed, Feb 22, 2023 at 11:51 AM Romain Manni-Bucau
 wrote:
>
> Eliotte I kind of fail to follow your reasoning because it literally means
> don't log any info and just set default log level to ERROR which I don't
> think will make anyone happy.

Thanks for saying this. I think I see the disconnect now. I'm saying
log the errors and identify what's an error and what isn't. Artifact
is 404? Log it. Artifact is slow? Log it. Artifact downloads just
fine: don't log it. Don't hide the real problems in a sea of useless
log junk.

> You also tend to think everything works all the time but network issues are
> not work/fail kind of issue, the hanging case is really bothering and
> downloading logs really help there when you can keep them.

Again, that is *NOT* what I am saying. I think that network issues are
a real problem which is why I want them to be much easier to find and
debug by not logging things that aren't problems.

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

Re: And while I'm on the subject of logging

2023-02-23 Thread Xeno Amess

you can add a config or parameter to do this.
BUT I need that log, please don't remove it

From: Kemal Soysal 
Sent: Thursday, February 23, 2023 5:39:08 PM
To: Maven Developers List 
Subject: Re: And while I'm on the subject of logging

+1 logback

> Am 23.02.2023 um 06:39 schrieb Guillaume Nodet :
>
> Maven Daemon uses logback instead of the simple logger.  This definitely
> allows more configuration freedom.
> Should we switch maven 4 to logback or log4j too ?
>
> Le mer. 22 févr. 2023 à 18:45, Ralph Goers  a
> écrit :
>
>> Might I suggest that you are never going to make everyone happy.  That is
>> why Logging frameworks such as Log4j support using Logger names, Log
>> Levels, and Markers as basic ways of categorizing log events. With those
>> you can continue to log events but filter them down to just what the user
>> wants.
>>
>> Unfortunately, doing this will tie you to a logging implementation if you
>> try to do it programmatically.  If you let the user supply (or override)
>> the logging configuration then this wouldn’t be an issue.
>>
>> Ralph
>>
>>> On Feb 22, 2023, at 5:54 AM, Romain Manni-Bucau 
>> wrote:
>>>
>>> +1 to Guillaume proposal for default behavior while -X still logs
>>> everything (in logs ;))
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>
>>>
>>>
>>> Le mer. 22 févr. 2023 à 13:33, Gary Gregory  a
>>> écrit :
>>>
>>>> This echoes IMO what a higher level app (Maven in this case) should do,
>>>> tell me when something unusual happens, like when something is taking a
>>>> long time. For us Windows users, the Explorer UI only pops up its
>> progress
>>>> dialog when you are copying "a lot" or its taking "a long time",
>> otherwise
>>>> it is quiet.
>>>>
>>>> Question: when I ask mvn for -U behavior, I do like to see the download
>>>> logging, because I am asking for non-default behavior, I expect the
>> extra
>>>> output.
>>>>
>>>> As previously mentioned, there won't be change that makes everyone
>> happy,
>>>> but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
>>>> folks happy.
>>>>
>>>> Gary
>>>>
>>>> On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:
>>>>
>>>>> I do agree that logging all downloads is unneeded, and I do agree that
>>>> the
>>>>> hanging case can happen quite often and one needs to be informed.
>>>>> However, both goals are not conflicting, we just need to enhance the
>>>>> logger/downloader to:
>>>>> * print a single statement that it starts downloading things
>>>>> * if a download is too slow (for example, nothing has been received
>>>> since
>>>>> a few seconds), log a warning message
>>>>> * log a summary when the download finished (like "Downloaded 5
>>>> artifacts
>>>>> from central and yyy repositories")
>>>>> It should not be very difficult to detect stalled downloads.
>>>>>
>>>>> Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau <
>> rmannibu...@gmail.com
>>>>>
>>>>> a
>>>>> écrit :
>>>>>
>>>>>> Eliotte I kind of fail to follow your reasoning because it literally
>>>>> means
>>>>>> don't log any info and just set default log level to ERROR which I
>>>> don't
>>>>>> think will make anyone happy.
>>>>>> You also tend to think everything works all the time but network
>> issues
>>>>> are
>>>>>> not work/fail kind of issue, the hanging case is really bothering and
>>>>>> downloading logs really help there when you can keep them.
>>>>>> Lastly downloads are not expected by maven after one build so being a
>>>> bit
>>>>>> more verbose is not an issue and going outside the machine should
>>>> likely
>>>>>> always

Re: And while I'm on the subject of logging

2023-02-23 Thread Kemal Soysal

+1 logback

> Am 23.02.2023 um 06:39 schrieb Guillaume Nodet :
> 
> Maven Daemon uses logback instead of the simple logger.  This definitely
> allows more configuration freedom.
> Should we switch maven 4 to logback or log4j too ?
> 
> Le mer. 22 févr. 2023 à 18:45, Ralph Goers  a
> écrit :
> 
>> Might I suggest that you are never going to make everyone happy.  That is
>> why Logging frameworks such as Log4j support using Logger names, Log
>> Levels, and Markers as basic ways of categorizing log events. With those
>> you can continue to log events but filter them down to just what the user
>> wants.
>> 
>> Unfortunately, doing this will tie you to a logging implementation if you
>> try to do it programmatically.  If you let the user supply (or override)
>> the logging configuration then this wouldn’t be an issue.
>> 
>> Ralph
>> 
>>> On Feb 22, 2023, at 5:54 AM, Romain Manni-Bucau 
>> wrote:
>>> 
>>> +1 to Guillaume proposal for default behavior while -X still logs
>>> everything (in logs ;))
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
>>> Le mer. 22 févr. 2023 à 13:33, Gary Gregory  a
>>> écrit :
>>> 
>>>> This echoes IMO what a higher level app (Maven in this case) should do,
>>>> tell me when something unusual happens, like when something is taking a
>>>> long time. For us Windows users, the Explorer UI only pops up its
>> progress
>>>> dialog when you are copying "a lot" or its taking "a long time",
>> otherwise
>>>> it is quiet.
>>>> 
>>>> Question: when I ask mvn for -U behavior, I do like to see the download
>>>> logging, because I am asking for non-default behavior, I expect the
>> extra
>>>> output.
>>>> 
>>>> As previously mentioned, there won't be change that makes everyone
>> happy,
>>>> but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
>>>> folks happy.
>>>> 
>>>> Gary
>>>> 
>>>> On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:
>>>> 
>>>>> I do agree that logging all downloads is unneeded, and I do agree that
>>>> the
>>>>> hanging case can happen quite often and one needs to be informed.
>>>>> However, both goals are not conflicting, we just need to enhance the
>>>>> logger/downloader to:
>>>>> * print a single statement that it starts downloading things
>>>>> * if a download is too slow (for example, nothing has been received
>>>> since
>>>>> a few seconds), log a warning message
>>>>> * log a summary when the download finished (like "Downloaded 5
>>>> artifacts
>>>>> from central and yyy repositories")
>>>>> It should not be very difficult to detect stalled downloads.
>>>>> 
>>>>> Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau <
>> rmannibu...@gmail.com
>>>>> 
>>>>> a
>>>>> écrit :
>>>>> 
>>>>>> Eliotte I kind of fail to follow your reasoning because it literally
>>>>> means
>>>>>> don't log any info and just set default log level to ERROR which I
>>>> don't
>>>>>> think will make anyone happy.
>>>>>> You also tend to think everything works all the time but network
>> issues
>>>>> are
>>>>>> not work/fail kind of issue, the hanging case is really bothering and
>>>>>> downloading logs really help there when you can keep them.
>>>>>> Lastly downloads are not expected by maven after one build so being a
>>>> bit
>>>>>> more verbose is not an issue and going outside the machine should
>>>> likely
>>>>>> always be logged at the beginning these days.
>>>>>> 
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>> <https://rmannibucau.metawerx.

Re: And while I'm on the subject of logging

2023-02-23 Thread Romain Manni-Bucau

-1 to switch to logback or log4j (in particular v2 which is still slow and
fatty).
Think what we need is a good system prop config, can be achieved with jul
(ex: https://www.yupiik.io/yupiik-logging/jul-integration.html).
What I like with mvnd is not logback but the jansi/terminal usage which
helps to keep active tasks shown.

Le jeu. 23 févr. 2023 à 08:08, Paul Hammant  a
écrit :

> I wrote much of
>
> https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=118163392#content/view/118163392
> 20 years back, and still stand by the basic message.
>
> Maven is a build tool though, and aims and reproducibility. Minimal output
> should be the default (console and log files). If someone wants more, they
> can run the build again with another —argument. Cough, I mean -Dargument
>

Re: And while I'm on the subject of logging

2023-02-22 Thread Paul Hammant

I wrote much of
https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=118163392#content/view/118163392
20 years back, and still stand by the basic message.

Maven is a build tool though, and aims and reproducibility. Minimal output
should be the default (console and log files). If someone wants more, they
can run the build again with another —argument. Cough, I mean -Dargument

Re: And while I'm on the subject of logging

2023-02-22 Thread Guillaume Nodet

Maven Daemon uses logback instead of the simple logger.  This definitely
allows more configuration freedom.
Should we switch maven 4 to logback or log4j too ?

Le mer. 22 févr. 2023 à 18:45, Ralph Goers  a
écrit :

> Might I suggest that you are never going to make everyone happy.  That is
> why Logging frameworks such as Log4j support using Logger names, Log
> Levels, and Markers as basic ways of categorizing log events. With those
> you can continue to log events but filter them down to just what the user
> wants.
>
> Unfortunately, doing this will tie you to a logging implementation if you
> try to do it programmatically.  If you let the user supply (or override)
> the logging configuration then this wouldn’t be an issue.
>
> Ralph
>
> > On Feb 22, 2023, at 5:54 AM, Romain Manni-Bucau 
> wrote:
> >
> > +1 to Guillaume proposal for default behavior while -X still logs
> > everything (in logs ;))
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 22 févr. 2023 à 13:33, Gary Gregory  a
> > écrit :
> >
> >> This echoes IMO what a higher level app (Maven in this case) should do,
> >> tell me when something unusual happens, like when something is taking a
> >> long time. For us Windows users, the Explorer UI only pops up its
> progress
> >> dialog when you are copying "a lot" or its taking "a long time",
> otherwise
> >> it is quiet.
> >>
> >> Question: when I ask mvn for -U behavior, I do like to see the download
> >> logging, because I am asking for non-default behavior, I expect the
> extra
> >> output.
> >>
> >> As previously mentioned, there won't be change that makes everyone
> happy,
> >> but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
> >> folks happy.
> >>
> >> Gary
> >>
> >> On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:
> >>
> >>> I do agree that logging all downloads is unneeded, and I do agree that
> >> the
> >>> hanging case can happen quite often and one needs to be informed.
> >>> However, both goals are not conflicting, we just need to enhance the
> >>> logger/downloader to:
> >>>  * print a single statement that it starts downloading things
> >>>  * if a download is too slow (for example, nothing has been received
> >> since
> >>> a few seconds), log a warning message
> >>>  * log a summary when the download finished (like "Downloaded 5
> >> artifacts
> >>> from central and yyy repositories")
> >>> It should not be very difficult to detect stalled downloads.
> >>>
> >>> Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>>
> >>> a
> >>> écrit :
> >>>
> >>>> Eliotte I kind of fail to follow your reasoning because it literally
> >>> means
> >>>> don't log any info and just set default log level to ERROR which I
> >> don't
> >>>> think will make anyone happy.
> >>>> You also tend to think everything works all the time but network
> issues
> >>> are
> >>>> not work/fail kind of issue, the hanging case is really bothering and
> >>>> downloading logs really help there when you can keep them.
> >>>> Lastly downloads are not expected by maven after one build so being a
> >> bit
> >>>> more verbose is not an issue and going outside the machine should
> >> likely
> >>>> always be logged at the beginning these days.
> >>>>
> >>>> Romain Manni-Bucau
> >>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>> <http://rmannibucau.wordpress.com> | Github <
> >>>> https://github.com/rmannibucau> |
> >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>> <
> >>>>
> >>>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>&g

Re: And while I'm on the subject of logging

2023-02-22 Thread Ralph Goers

Might I suggest that you are never going to make everyone happy.  That is why 
Logging frameworks such as Log4j support using Logger names, Log Levels, and 
Markers as basic ways of categorizing log events. With those you can continue 
to log events but filter them down to just what the user wants. 

Unfortunately, doing this will tie you to a logging implementation if you try 
to do it programmatically.  If you let the user supply (or override) the 
logging configuration then this wouldn’t be an issue.

Ralph

> On Feb 22, 2023, at 5:54 AM, Romain Manni-Bucau  wrote:
> 
> +1 to Guillaume proposal for default behavior while -X still logs
> everything (in logs ;))
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le mer. 22 févr. 2023 à 13:33, Gary Gregory  a
> écrit :
> 
>> This echoes IMO what a higher level app (Maven in this case) should do,
>> tell me when something unusual happens, like when something is taking a
>> long time. For us Windows users, the Explorer UI only pops up its progress
>> dialog when you are copying "a lot" or its taking "a long time", otherwise
>> it is quiet.
>> 
>> Question: when I ask mvn for -U behavior, I do like to see the download
>> logging, because I am asking for non-default behavior, I expect the extra
>> output.
>> 
>> As previously mentioned, there won't be change that makes everyone happy,
>> but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
>> folks happy.
>> 
>> Gary
>> 
>> On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:
>> 
>>> I do agree that logging all downloads is unneeded, and I do agree that
>> the
>>> hanging case can happen quite often and one needs to be informed.
>>> However, both goals are not conflicting, we just need to enhance the
>>> logger/downloader to:
>>>  * print a single statement that it starts downloading things
>>>  * if a download is too slow (for example, nothing has been received
>> since
>>> a few seconds), log a warning message
>>>  * log a summary when the download finished (like "Downloaded 5
>> artifacts
>>> from central and yyy repositories")
>>> It should not be very difficult to detect stalled downloads.
>>> 
>>> Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau >> 
>>> a
>>> écrit :
>>> 
>>>> Eliotte I kind of fail to follow your reasoning because it literally
>>> means
>>>> don't log any info and just set default log level to ERROR which I
>> don't
>>>> think will make anyone happy.
>>>> You also tend to think everything works all the time but network issues
>>> are
>>>> not work/fail kind of issue, the hanging case is really bothering and
>>>> downloading logs really help there when you can keep them.
>>>> Lastly downloads are not expected by maven after one build so being a
>> bit
>>>> more verbose is not an issue and going outside the machine should
>> likely
>>>> always be logged at the beginning these days.
>>>> 
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>> <http://rmannibucau.wordpress.com> | Github <
>>>> https://github.com/rmannibucau> |
>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>> <
>>>> 
>>> 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>>> 
>>>> 
>>>> 
>>>> Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold <
>> elh...@ibiblio.org
>>>> 
>>>> a
>>>> écrit :
>>>> 
>>>>> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
>>>>>  wrote:
>>>>>> 
>>>>>> 
>>>>>> except there is no issue, the download is just slow so why
>> would
>>>> you
>>>>>> fail?
>>>>>> Hapoy to discuss a better solution but logging is a very satisfying
>>>> one.
>>>>> 
>>>>> If there is no issue, don't log it. If

Re: And while I'm on the subject of logging

2023-02-22 Thread Romain Manni-Bucau

+1 to Guillaume proposal for default behavior while -X still logs
everything (in logs ;))

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 22 févr. 2023 à 13:33, Gary Gregory  a
écrit :

> This echoes IMO what a higher level app (Maven in this case) should do,
> tell me when something unusual happens, like when something is taking a
> long time. For us Windows users, the Explorer UI only pops up its progress
> dialog when you are copying "a lot" or its taking "a long time", otherwise
> it is quiet.
>
> Question: when I ask mvn for -U behavior, I do like to see the download
> logging, because I am asking for non-default behavior, I expect the extra
> output.
>
> As previously mentioned, there won't be change that makes everyone happy,
> but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
> folks happy.
>
> Gary
>
> On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:
>
> > I do agree that logging all downloads is unneeded, and I do agree that
> the
> > hanging case can happen quite often and one needs to be informed.
> > However, both goals are not conflicting, we just need to enhance the
> > logger/downloader to:
> >   * print a single statement that it starts downloading things
> >   * if a download is too slow (for example, nothing has been received
> since
> > a few seconds), log a warning message
> >   * log a summary when the download finished (like "Downloaded 5
> artifacts
> > from central and yyy repositories")
> > It should not be very difficult to detect stalled downloads.
> >
> > Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau  >
> > a
> > écrit :
> >
> > > Eliotte I kind of fail to follow your reasoning because it literally
> > means
> > > don't log any info and just set default log level to ERROR which I
> don't
> > > think will make anyone happy.
> > > You also tend to think everything works all the time but network issues
> > are
> > > not work/fail kind of issue, the hanging case is really bothering and
> > > downloading logs really help there when you can keep them.
> > > Lastly downloads are not expected by maven after one build so being a
> bit
> > > more verbose is not an issue and going outside the machine should
> likely
> > > always be logged at the beginning these days.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold <
> elh...@ibiblio.org
> > >
> > > a
> > > écrit :
> > >
> > > > On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
> > > >  wrote:
> > > > >
> > > > >
> > > > > except there is no issue, the download is just slow so why
> would
> > > you
> > > > > fail?
> > > > > Hapoy to discuss a better solution but logging is a very satisfying
> > > one.
> > > >
> > > > If there is no issue, don't log it. If being slow is an issue
> > > > (arguably it isn't) report it when it's slow enough to be an issue,
> > > > and only then. Too many developer tools don't finish the job by
> > > > accurately diagnosing and reporting on errors. Instead they throw up
> > > > their hands and say, "Oops. Something went wrong. Here's an
> > > > incomprehensible dump of 50% of everything that happened. Maybe the
> > > > thing that went wrong is in there somewhere. Maybe it isn't. You
> > > > figure it out."
> > > >
> > > > Imagine a compiler that instead of identifying the offending line of
> > > > syntactically incorrect code simply printed every line of source code
> > > > as it parsed it, twice. Would anyone put up with such a compiler or
> > > > would the bug reports overflow the Github issue tracker? Why do we
> > > > accept that level of error reporting in Maven downloads?
> > > >
> > > > We shouldn't force people to do what computers can easily do. One of
> > > > the things a computer can do is notice when one out of hundreds of
> > > > dependencies is causing a problem, and blame  exactly that one
> > > > artifact.
> > > >
> > > > --
> > > > 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
> > > >
> > > >
> > >
> >
> >
> > --
> > 
> > Guillaume Nodet
> >
>

Re: And while I'm on the subject of logging

2023-02-22 Thread Gary Gregory

This echoes IMO what a higher level app (Maven in this case) should do,
tell me when something unusual happens, like when something is taking a
long time. For us Windows users, the Explorer UI only pops up its progress
dialog when you are copying "a lot" or its taking "a long time", otherwise
it is quiet.

Question: when I ask mvn for -U behavior, I do like to see the download
logging, because I am asking for non-default behavior, I expect the extra
output.

As previously mentioned, there won't be change that makes everyone happy,
but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
folks happy.

Gary

On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:

> I do agree that logging all downloads is unneeded, and I do agree that the
> hanging case can happen quite often and one needs to be informed.
> However, both goals are not conflicting, we just need to enhance the
> logger/downloader to:
>   * print a single statement that it starts downloading things
>   * if a download is too slow (for example, nothing has been received since
> a few seconds), log a warning message
>   * log a summary when the download finished (like "Downloaded 5 artifacts
> from central and yyy repositories")
> It should not be very difficult to detect stalled downloads.
>
> Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau 
> a
> écrit :
>
> > Eliotte I kind of fail to follow your reasoning because it literally
> means
> > don't log any info and just set default log level to ERROR which I don't
> > think will make anyone happy.
> > You also tend to think everything works all the time but network issues
> are
> > not work/fail kind of issue, the hanging case is really bothering and
> > downloading logs really help there when you can keep them.
> > Lastly downloads are not expected by maven after one build so being a bit
> > more verbose is not an issue and going outside the machine should likely
> > always be logged at the beginning these days.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold  >
> > a
> > écrit :
> >
> > > On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
> > >  wrote:
> > > >
> > > >
> > > > except there is no issue, the download is just slow so why would
> > you
> > > > fail?
> > > > Hapoy to discuss a better solution but logging is a very satisfying
> > one.
> > >
> > > If there is no issue, don't log it. If being slow is an issue
> > > (arguably it isn't) report it when it's slow enough to be an issue,
> > > and only then. Too many developer tools don't finish the job by
> > > accurately diagnosing and reporting on errors. Instead they throw up
> > > their hands and say, "Oops. Something went wrong. Here's an
> > > incomprehensible dump of 50% of everything that happened. Maybe the
> > > thing that went wrong is in there somewhere. Maybe it isn't. You
> > > figure it out."
> > >
> > > Imagine a compiler that instead of identifying the offending line of
> > > syntactically incorrect code simply printed every line of source code
> > > as it parsed it, twice. Would anyone put up with such a compiler or
> > > would the bug reports overflow the Github issue tracker? Why do we
> > > accept that level of error reporting in Maven downloads?
> > >
> > > We shouldn't force people to do what computers can easily do. One of
> > > the things a computer can do is notice when one out of hundreds of
> > > dependencies is causing a problem, and blame  exactly that one
> > > artifact.
> > >
> > > --
> > > 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
> > >
> > >
> >
>
>
> --
> 
> Guillaume Nodet
>

Re: And while I'm on the subject of logging

2023-02-22 Thread Delany

Another example of excessive logging prompting one to find the root cause:

On Mon, 6 Feb 2023 at 15:03, James Agnew  wrote:

> Just to close the loop in case anyone finds this post.
>
> I had discounted the idea that a version range was the cause because I went
> over all of the POMs in my project and was sure none of them had a range
> version. I ended up attaching a debugger to Maven to try and figure out why
> it was doing all of this resolving and discovering... one of the libraries
> I had as a dependency in one of my modules had a range for the same
> dependency that I was importing with a specific version in my own module.
>
>
>
> On Fri, Jan 27, 2023 at 7:47 PM Łukasz Dywicki 
> wrote:
>
> > Hello James,
> > You can configure snapshot repository to have custom update interval.
> > However from your mail I can smell some version range being used as
> > Maven would normally go only to remote repos to check is there a new
> > build of 6.3.14-SNAPSHOT of hapi-fhir-base. If you see
> > 6.1.0-PRE1-SNAPSHOT its most likely being checked because of a range
> > which is defined for hapi-fhir-base, one of its dependencies or other
> > dependencies you list in your project.
> >
> > To reduce amount of repository round trips please have a look on Maven
> > settings reference:
> > https://maven.apache.org/settings.html#Repositories
> >
> > Option you may look at is updatePolicy which can be specified inside
> >  element. There are several values available. For example
> > always, daily, never, interval:X (where X stands for minutes).
> > Switching to inverval:24 might prevent you from seeing update check
> > after midnight, but you will have it at the start of every day!
> >
> > Hope that it helps you . ;-)
> > Łukasz
> > --
> > http://code-house.org
> > PS. Thank you for a great library!
> >
> > On 27.01.2023 22:47, James Agnew wrote:
> > > I'm wondering if this is something others have seen and perhaps
> something
> > > I'm doing wrong.
> > >
> > > I have a Maven project that uses a SNAPSHOT version of a library. I
> know
> > > Maven needs to check the maven-metadata.xml file every day in order to
> > > check if a new version of the snapshot is available, but in my case it
> > > seems to be downloading this file for every version of the snapshot
> that
> > > ever existed.
> > >
> > > My pom.xml references the dependency ca.uhn.hapi.fhir:hapi-fhir-base
> with
> > > 6.3.14-SNAPSHOT, but in my build logs I see lines
> such
> > > as:
> > >
> > > 16:34:58.543 INFO Downloading from oss-snapshots:
> > >
> >
> https://oss.sonatype.org/content/repositories/snapshots/ca/uhn/hapi/fhir/hapi-fhir/6.1.0-PRE1-SNAPSHOT/maven-metadata.xml
> > > 16:36:29.663 INFO Downloading from oss-snapshots:
> > >
> >
> https://oss.sonatype.org/content/repositories/snapshots/ca/uhn/hapi/fhir/hapi-fhir-base/6.1.0-PRE2-SNAPSHOT/maven-metadata.xml
> > > 16:36:34.835 INFO Downloading from oss-snapshots:
> > >
> >
> https://oss.sonatype.org/content/repositories/snapshots/ca/uhn/hapi/fhir/hapi-fhir-base/6.1.0-PRE3-SNAPSHOT/maven-metadata.xml
> > >
> > > ..and many more. Downloading all of these versions for all of the
> modules
> > > in this library is adding tons of time and noise to my build. Is there
> a
> > > way to configure Maven to not do this?
> > >
> > > Cheers,
> > > James
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: And while I'm on the subject of logging

2023-02-22 Thread Delany

You're arguing based on principles, but my experience suggests otherwise.
Some real life examples:
https://issues.apache.org/jira/browse/MENFORCER-462
https://issues.apache.org/jira/browse/MNG-7214

I would not have noticed or logged either of these issues without logging.
Its because they were logged that I noticed them.

Since Maven is so complex, and the configuration is declarative, the only
way to understand runtime execution is logging or debugging.
Info-level logging has helped me understand how Maven operates. I learn
next to nothing from -X logs.

Another assumption you make is that only errors matter. Plenty of times my
build succeeded, but it didn't produce the artifacts the way I wanted them.
Diffing the logs, no matter how verbose, could show me why the output is
different. But not if they're both blank.

On Wed, 22 Feb 2023 at 13:40, Elliotte Rusty Harold 
wrote:

> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
>  wrote:
> >
> >
> > except there is no issue, the download is just slow so why would you
> > fail?
> > Hapoy to discuss a better solution but logging is a very satisfying one.
>
> If there is no issue, don't log it. If being slow is an issue
> (arguably it isn't) report it when it's slow enough to be an issue,
> and only then. Too many developer tools don't finish the job by
> accurately diagnosing and reporting on errors. Instead they throw up
> their hands and say, "Oops. Something went wrong. Here's an
> incomprehensible dump of 50% of everything that happened. Maybe the
> thing that went wrong is in there somewhere. Maybe it isn't. You
> figure it out."
>
> Imagine a compiler that instead of identifying the offending line of
> syntactically incorrect code simply printed every line of source code
> as it parsed it, twice. Would anyone put up with such a compiler or
> would the bug reports overflow the Github issue tracker? Why do we
> accept that level of error reporting in Maven downloads?
>
> We shouldn't force people to do what computers can easily do. One of
> the things a computer can do is notice when one out of hundreds of
> dependencies is causing a problem, and blame  exactly that one
> artifact.
>
> --
> 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
>
>

Re: And while I'm on the subject of logging

2023-02-22 Thread Kemal Soysal

The logging discussion is well underway.
According to my experience with build management,
there has always been these contradicting requirements no logging to heaps of 
more logging in case of an error.
If the build seemed to run smoothly you were fooled by everything looking fine, 
unless you saw the output with -X -e.
Therefore our build pipeline always switched to full output.
Locally for the development build we just had info.

For combining these contradictions we decided to log into a file by providing 
the -l -, 
so the output is saved quicker on disk for local builds and is not blocked by 
the terminal 
(specially under windows with the small output buffer and sometimes someone 
accidentally marking a spot that blocks the process io), 
and with an adjacent check script we could assure that certain unwelcome 
situations could be detected.

From this experience… I would suggest to bring in a configurable log validator, 
that can be extended to specific needs, to judge the outcome of the build too.
Not everything of a green build is ok.
The custom validator can collect information about these problems and report 
them well.

These are my 2 cents or less,

Best Regards


> Am 22.02.2023 um 12:56 schrieb Guillaume Nodet :
> 
> I do agree that logging all downloads is unneeded, and I do agree that the
> hanging case can happen quite often and one needs to be informed.
> However, both goals are not conflicting, we just need to enhance the
> logger/downloader to:
>  * print a single statement that it starts downloading things
>  * if a download is too slow (for example, nothing has been received since
> a few seconds), log a warning message
>  * log a summary when the download finished (like "Downloaded 5 artifacts
> from central and yyy repositories")
> It should not be very difficult to detect stalled downloads.
> 
> Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau  a
> écrit :
> 
>> Eliotte I kind of fail to follow your reasoning because it literally means
>> don't log any info and just set default log level to ERROR which I don't
>> think will make anyone happy.
>> You also tend to think everything works all the time but network issues are
>> not work/fail kind of issue, the hanging case is really bothering and
>> downloading logs really help there when you can keep them.
>> Lastly downloads are not expected by maven after one build so being a bit
>> more verbose is not an issue and going outside the machine should likely
>> always be logged at the beginning these days.
>> 
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>> 
>> 
>> Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold 
>> a
>> écrit :
>> 
>>> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
>>>  wrote:
>>>> 
>>>> 
>>>> except there is no issue, the download is just slow so why would
>> you
>>>> fail?
>>>> Hapoy to discuss a better solution but logging is a very satisfying
>> one.
>>> 
>>> If there is no issue, don't log it. If being slow is an issue
>>> (arguably it isn't) report it when it's slow enough to be an issue,
>>> and only then. Too many developer tools don't finish the job by
>>> accurately diagnosing and reporting on errors. Instead they throw up
>>> their hands and say, "Oops. Something went wrong. Here's an
>>> incomprehensible dump of 50% of everything that happened. Maybe the
>>> thing that went wrong is in there somewhere. Maybe it isn't. You
>>> figure it out."
>>> 
>>> Imagine a compiler that instead of identifying the offending line of
>>> syntactically incorrect code simply printed every line of source code
>>> as it parsed it, twice. Would anyone put up with such a compiler or
>>> would the bug reports overflow the Github issue tracker? Why do we
>>> accept that level of error reporting in Maven downloads?
>>> 
>>> We shouldn't force people to do what computers can easily do. One of
>>> the things a computer can do is notice when one out of hundreds of
>>> dependencies is causing a problem, and blame  exactly that one
>>> artifact.
>>> 
>>> --
>>> 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
>>> 
>>> 
>> 
> 
> 
> -- 
> 
> Guillaume Nodet


--
Kemal Soysal


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

Re: And while I'm on the subject of logging

2023-02-22 Thread Guillaume Nodet

I do agree that logging all downloads is unneeded, and I do agree that the
hanging case can happen quite often and one needs to be informed.
However, both goals are not conflicting, we just need to enhance the
logger/downloader to:
  * print a single statement that it starts downloading things
  * if a download is too slow (for example, nothing has been received since
a few seconds), log a warning message
  * log a summary when the download finished (like "Downloaded 5 artifacts
from central and yyy repositories")
It should not be very difficult to detect stalled downloads.

Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau  a
écrit :

> Eliotte I kind of fail to follow your reasoning because it literally means
> don't log any info and just set default log level to ERROR which I don't
> think will make anyone happy.
> You also tend to think everything works all the time but network issues are
> not work/fail kind of issue, the hanging case is really bothering and
> downloading logs really help there when you can keep them.
> Lastly downloads are not expected by maven after one build so being a bit
> more verbose is not an issue and going outside the machine should likely
> always be logged at the beginning these days.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold 
> a
> écrit :
>
> > On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
> >  wrote:
> > >
> > >
> > > except there is no issue, the download is just slow so why would
> you
> > > fail?
> > > Hapoy to discuss a better solution but logging is a very satisfying
> one.
> >
> > If there is no issue, don't log it. If being slow is an issue
> > (arguably it isn't) report it when it's slow enough to be an issue,
> > and only then. Too many developer tools don't finish the job by
> > accurately diagnosing and reporting on errors. Instead they throw up
> > their hands and say, "Oops. Something went wrong. Here's an
> > incomprehensible dump of 50% of everything that happened. Maybe the
> > thing that went wrong is in there somewhere. Maybe it isn't. You
> > figure it out."
> >
> > Imagine a compiler that instead of identifying the offending line of
> > syntactically incorrect code simply printed every line of source code
> > as it parsed it, twice. Would anyone put up with such a compiler or
> > would the bug reports overflow the Github issue tracker? Why do we
> > accept that level of error reporting in Maven downloads?
> >
> > We shouldn't force people to do what computers can easily do. One of
> > the things a computer can do is notice when one out of hundreds of
> > dependencies is causing a problem, and blame  exactly that one
> > artifact.
> >
> > --
> > 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
> >
> >
>


-- 

Guillaume Nodet

Re: And while I'm on the subject of logging

2023-02-22 Thread Romain Manni-Bucau

Eliotte I kind of fail to follow your reasoning because it literally means
don't log any info and just set default log level to ERROR which I don't
think will make anyone happy.
You also tend to think everything works all the time but network issues are
not work/fail kind of issue, the hanging case is really bothering and
downloading logs really help there when you can keep them.
Lastly downloads are not expected by maven after one build so being a bit
more verbose is not an issue and going outside the machine should likely
always be logged at the beginning these days.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold  a
écrit :

> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
>  wrote:
> >
> >
> > except there is no issue, the download is just slow so why would you
> > fail?
> > Hapoy to discuss a better solution but logging is a very satisfying one.
>
> If there is no issue, don't log it. If being slow is an issue
> (arguably it isn't) report it when it's slow enough to be an issue,
> and only then. Too many developer tools don't finish the job by
> accurately diagnosing and reporting on errors. Instead they throw up
> their hands and say, "Oops. Something went wrong. Here's an
> incomprehensible dump of 50% of everything that happened. Maybe the
> thing that went wrong is in there somewhere. Maybe it isn't. You
> figure it out."
>
> Imagine a compiler that instead of identifying the offending line of
> syntactically incorrect code simply printed every line of source code
> as it parsed it, twice. Would anyone put up with such a compiler or
> would the bug reports overflow the Github issue tracker? Why do we
> accept that level of error reporting in Maven downloads?
>
> We shouldn't force people to do what computers can easily do. One of
> the things a computer can do is notice when one out of hundreds of
> dependencies is causing a problem, and blame  exactly that one
> artifact.
>
> --
> 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
>
>

Re: And while I'm on the subject of logging

2023-02-22 Thread Elliotte Rusty Harold

On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
 wrote:
>
>
> except there is no issue, the download is just slow so why would you
> fail?
> Hapoy to discuss a better solution but logging is a very satisfying one.

If there is no issue, don't log it. If being slow is an issue
(arguably it isn't) report it when it's slow enough to be an issue,
and only then. Too many developer tools don't finish the job by
accurately diagnosing and reporting on errors. Instead they throw up
their hands and say, "Oops. Something went wrong. Here's an
incomprehensible dump of 50% of everything that happened. Maybe the
thing that went wrong is in there somewhere. Maybe it isn't. You
figure it out."

Imagine a compiler that instead of identifying the offending line of
syntactically incorrect code simply printed every line of source code
as it parsed it, twice. Would anyone put up with such a compiler or
would the bug reports overflow the Github issue tracker? Why do we
accept that level of error reporting in Maven downloads?

We shouldn't force people to do what computers can easily do. One of
the things a computer can do is notice when one out of hundreds of
dependencies is causing a problem, and blame  exactly that one
artifact.

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

Re: And while I'm on the subject of logging

2023-02-21 Thread Romain Manni-Bucau

Le mar. 21 févr. 2023 à 21:16, Elliotte Rusty Harold  a
écrit :

> On Tue, Feb 21, 2023 at 3:07 PM Romain Manni-Bucau
>  wrote:
>
> > In terms of default I think default should match the most common case and
> > downloads is not a common case for maven but a very troublesome one when
> it
> > fails or hangs and not logging anything means maven hangs for end user
> > without idea why until you kill -3 it which is often hard on CI so think
> > "downloading" info is key there, similarly "downloaded" enables to know
> an
> > artifact and from where is used in classpath(s) which is key for the same
> > reason.
>
> Logging is **not** a solution for this problem. It is a band-aid, and
> a poor one. Maven itself should not hang. Instead Maven should
> explicitly fail and log a detailed error message when a download
> fails. That is, it should report the actual problem. It should not
> report 999 things that happened before the problem and expect the user
> infer what the problem is, like trying to get someone to imagine an
> ele[hant in a room by describing everything in the room that is not an
> elephant and asking them to notice the elephant shaped hole in the
> description.
>


except there is no issue, the download is just slow so why would you
fail?
Hapoy to discuss a better solution but logging is a very satisfying one.

The elephant metaphore works if you add "when the elephant is there" which
is rare so ok.

Think you chase a misconfig of CI/machine issue more than a maven issue.


> If Maven indeed fails to recognize and report a failed or hung
> download, please file a bug in Jira.
>
> --
> 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
>
>

Re: And while I'm on the subject of logging

2023-02-21 Thread Elliotte Rusty Harold

On Tue, Feb 21, 2023 at 3:07 PM Romain Manni-Bucau
 wrote:

> In terms of default I think default should match the most common case and
> downloads is not a common case for maven but a very troublesome one when it
> fails or hangs and not logging anything means maven hangs for end user
> without idea why until you kill -3 it which is often hard on CI so think
> "downloading" info is key there, similarly "downloaded" enables to know an
> artifact and from where is used in classpath(s) which is key for the same
> reason.

Logging is **not** a solution for this problem. It is a band-aid, and
a poor one. Maven itself should not hang. Instead Maven should
explicitly fail and log a detailed error message when a download
fails. That is, it should report the actual problem. It should not
report 999 things that happened before the problem and expect the user
infer what the problem is, like trying to get someone to imagine an
ele[hant in a room by describing everything in the room that is not an
elephant and asking them to notice the elephant shaped hole in the
description.

If Maven indeed fails to recognize and report a failed or hung
download, please file a bug in Jira.

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

Re: And while I'm on the subject of logging

2023-02-21 Thread Romain Manni-Bucau

What I dislike with -vvv or --log-level=[debug|info|...] is your control is
basically all or nothing (maven -q/-X, podman, curl i'm looking at your
shortcuts ;)) whereas being able to configure log level per logger name on
the CLI (ideally with completion) enables you to configure exactly what you
need and relevant.

In terms of default I think default should match the most common case and
downloads is not a common case for maven but a very troublesome one when it
fails or hangs and not logging anything means maven hangs for end user
without idea why until you kill -3 it which is often hard on CI so think
"downloading" info is key there, similarly "downloaded" enables to know an
artifact and from where is used in classpath(s) which is key for the same
reason.
Switching it off will not help human beings since they don't see the lines
most of the time (you don't drop your repo everyday and if you are bothered
with snapshots you -o) so it is really about machines/CI and there it is
relevant to have that info while CI is friendly - ie not travis or CI with
a limited output - IMHO.

Guess ultimately you can maybe join https://github.com/apache/maven/pull/869
.
Idea is to make the default (all) CI friendly by enabling *-B -q* but
having a toggle to disable it for other env.

So my 2 cts would be:

1. move the PR forward which seems to reach your expectation and enable to
make others happy since the revert is 1 short toggle - pby the doc to
enhance
2. ensure we can tune more easily the logging for advanced cases (simpler
logger keys are way too long and often need a file to be usable IMHO)
3. replace the System.out listener with logger*s* (one per event)
4. (optional) make the UI more interactive with a list of pending tasks at
the bottom - can be hard to keep portabe but would be more user friendly?

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 21 févr. 2023 à 20:14, Christoph Läubrich  a
écrit :

> A common way to control "verbosity" in commandline application is having:
>
> default : as silent as possible
> -v : show some level of output (e.g. "Downloading dependencies ...")
> -vv   : show more (e.g. Start downloading / stop downloading)
> -vvv  : even more
>
> This could easily adopted for other areas of maven, e.g.
>
> [INFO] --- maven-compiler-plugin:3.10.1:testCompile
> (default-testCompile) @ tycho-source-plugin ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to
> /home/christoph/git/laeubi/tycho/tycho-source-plugin/target/test-classes
>
> [INFO] --- maven-jar-plugin:3.3.0:jar (default-jar) @
> tycho-sourceref-jgit ---
> [INFO] Building jar:
>
> /home/christoph/git/laeubi/tycho/tycho-extras/tycho-sourceref-jgit/target/tycho-sourceref-jgit-4.0.0-SNAPSHOT.jar
>
> [INFO] --- maven-surefire-plugin:3.0.0-M9:test (default-test) @
> tycho-sourceref-jgit ---
> [INFO] Tests are skipped.
>
> [INFO] --- maven-plugin-plugin:3.7.1:descriptor (default-descriptor) @
> tycho-source-plugin ---
> [INFO] Using 'UTF-8' encoding to read mojo source files.
>
>
> all these extra messages can be suppressed most of the time.
>
>
> So a default maven run with lowest verbosity message maybe even just
> print the following:
>
> Building my.project:module1:123 ...
> Building my.project:module2:345 ...
> Building my.project:module3:345 ...
> Build success!
>
>
>
>
>
> Am 21.02.23 um 19:59 schrieb Elliotte Rusty Harold:
> > A general pattern I notice in discussions of excessive logging — not
> > just here and not only involving Maven — is to describe a scenario in
> > which a certain log message is useful. This is not hard to do but does
> > not justify the log message. Instead it is necessary to estimate how
> > often that log message will be read and acted on. Any log message that
> > is likely to be acted on less than 1% of the time (often a lot less)
> > should not be turned on by default. It does far more harm by hiding
> > real problems than it does by once in a blue moon giving someone
> > useful info.
> >
> > The only log messages that should be shown to the developer by default
> > are ones that are expected to be acted on. For instance, a failed
> > assert in a unit test should be logged because the whole point of
> > running a unit test is to fix failures. However a passed assertion
> > should log absolutely nothing by default because no action needs to be
&

Re: And while I'm on the subject of logging

2023-02-21 Thread Christoph Läubrich

A common way to control "verbosity" in commandline application is having:

default : as silent as possible
-v : show some level of output (e.g. "Downloading dependencies ...")
-vv : show more (e.g. Start downloading / stop downloading)
-vvv : even more

This could easily adopted for other areas of maven, e.g.

[INFO] --- maven-compiler-plugin:3.10.1:testCompile
(default-testCompile) @ tycho-source-plugin ---

[INFO] Changes detected - recompiling the module!
[INFO] Compiling 2 source files to
/home/christoph/git/laeubi/tycho/tycho-source-plugin/target/test-classes

[INFO] --- maven-jar-plugin:3.3.0:jar (default-jar) @
tycho-sourceref-jgit ---
[INFO] Building jar:
/home/christoph/git/laeubi/tycho/tycho-extras/tycho-sourceref-jgit/target/tycho-sourceref-jgit-4.0.0-SNAPSHOT.jar

[INFO] --- maven-surefire-plugin:3.0.0-M9:test (default-test) @
tycho-sourceref-jgit ---

[INFO] Tests are skipped.

[INFO] --- maven-plugin-plugin:3.7.1:descriptor (default-descriptor) @
tycho-source-plugin ---

[INFO] Using 'UTF-8' encoding to read mojo source files.

all these extra messages can be suppressed most of the time.

So a default maven run with lowest verbosity message maybe even just
print the following:

Building my.project:module1:123 ...
Building my.project:module2:345 ...
Building my.project:module3:345 ...
Build success!

Am 21.02.23 um 19:59 schrieb Elliotte Rusty Harold:

A general pattern I notice in discussions of excessive logging — not
just here and not only involving Maven — is to describe a scenario in
which a certain log message is useful. This is not hard to do but does
not justify the log message. Instead it is necessary to estimate how
often that log message will be read and acted on. Any log message that
is likely to be acted on less than 1% of the time (often a lot less)
should not be turned on by default. It does far more harm by hiding
real problems than it does by once in a blue moon giving someone
useful info.

The only log messages that should be shown to the developer by default
are ones that are expected to be acted on. For instance, a failed
assert in a unit test should be logged because the whole point of
running a unit test is to fix failures. However a passed assertion
should log absolutely nothing by default because no action needs to be
taken given a passed test. Logs like Maven's are UIs, and UIs that are
cluttered with unactionable, unimportant information are hard to
understand and work with. Show the developer what the developer needs
to know, and nothing else.

On Tue, Feb 21, 2023 at 1:28 PM Piotr P. Karwasz
wrote:

Hi Elliotte,

On Mon, 20 Feb 2023 at 19:51, Elliotte Rusty Harold wrote:

I don't believe anyone reads most of these messages most of the time.
In fact, I'd venture that well more than 99% of them are never read by
anyone.

Some people started reading these after Log4Shell. On StackOverflow
questions like "Why is Maven downloading ...?"[1]

If I might add my 2 cents, the right amount of logging should:

1. allow people with 56 Kbps connections to understand why the build
is taking ages,
2. inform the other users (that set -ntp), what does Maven download and why.

The second case could have logs like:

Downloading plugin dependencies:
org.apache.maven.plugins:maven-compiler-plugin:3.11.0,
org.apache.maven.shared:maven.shared.utils:3.3.4, ...
Downloading compile dependencies: org.apache.logging.log4j:log4j-api:2.20.0, ...

Not sure if this should be at INFO or DEBUG level: during a CI build
this info is important to understand whether a fresh snapshot was
downloaded from a remote repo or the one installed locally (e.g. in
the previous step) is being used.

Piotr

[1] https://stackoverflow.com/q/70473780/11748454

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

Re: And while I'm on the subject of logging

2023-02-21 Thread Elliotte Rusty Harold

A general pattern I notice in discussions of excessive logging — not
just here and not only involving Maven — is to describe a scenario in
which a certain log message is useful. This is not hard to do but does
not justify the log message. Instead it is necessary to estimate how
often that log message will be read and acted on. Any log message that
is likely to be acted on less than 1% of the time (often a lot less)
should not be turned on by default. It does far more harm by hiding
real problems than it does by once in a blue moon giving someone
useful info.

The only log messages that should be shown to the developer by default
are ones that are expected to be acted on. For instance, a failed
assert in a unit test should be logged because the whole point of
running a unit test is to fix failures. However a passed assertion
should log absolutely nothing by default because no action needs to be
taken given a passed test. Logs like Maven's are UIs, and UIs that are
cluttered with unactionable, unimportant information are hard to
understand and work with. Show the developer what the developer needs
to know, and nothing else.

On Tue, Feb 21, 2023 at 1:28 PM Piotr P. Karwasz
 wrote:
>
> Hi Elliotte,
>
> On Mon, 20 Feb 2023 at 19:51, Elliotte Rusty Harold  
> wrote:
> > I don't believe anyone reads most of these messages most of the time.
> > In fact, I'd venture that well more than 99% of them are never read by
> > anyone.
>
> Some people started reading these after Log4Shell. On StackOverflow
> questions like "Why is Maven downloading ...?"[1]
>
> If I might add my 2 cents, the right amount of logging should:
>
> 1. allow people with 56 Kbps connections to understand why the build
> is taking ages,
> 2. inform the other users (that set -ntp), what does Maven download and why.
>
> The second case could have logs like:
>
> Downloading plugin dependencies:
> org.apache.maven.plugins:maven-compiler-plugin:3.11.0,
> org.apache.maven.shared:maven.shared.utils:3.3.4, ...
> Downloading compile dependencies: org.apache.logging.log4j:log4j-api:2.20.0, 
> ...
>
> Not sure if this should be at INFO or DEBUG level: during a CI build
> this info is important to understand whether a fresh snapshot was
> downloaded from a remote repo or the one installed locally (e.g. in
> the previous step) is being used.
>
> Piotr
>
> [1] https://stackoverflow.com/q/70473780/11748454
>
> -
> 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

Re: And while I'm on the subject of logging

2023-02-21 Thread Piotr P. Karwasz

Hi Elliotte,

On Mon, 20 Feb 2023 at 19:51, Elliotte Rusty Harold  wrote:
> I don't believe anyone reads most of these messages most of the time.
> In fact, I'd venture that well more than 99% of them are never read by
> anyone.

Some people started reading these after Log4Shell. On StackOverflow
questions like "Why is Maven downloading ...?"[1]

If I might add my 2 cents, the right amount of logging should:

1. allow people with 56 Kbps connections to understand why the build
is taking ages,
2. inform the other users (that set -ntp), what does Maven download and why.

The second case could have logs like:

Downloading plugin dependencies:
org.apache.maven.plugins:maven-compiler-plugin:3.11.0,
org.apache.maven.shared:maven.shared.utils:3.3.4, ...
Downloading compile dependencies: org.apache.logging.log4j:log4j-api:2.20.0, ...

Not sure if this should be at INFO or DEBUG level: during a CI build
this info is important to understand whether a fresh snapshot was
downloaded from a remote repo or the one installed locally (e.g. in
the previous step) is being used.

Piotr

[1] https://stackoverflow.com/q/70473780/11748454

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

Re: And while I'm on the subject of logging

2023-02-20 Thread Delany

I wouldn't miss a thing past line 2. Since its all ERROR I have no control

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile
(default-compile) on project error_prone_core: Compilation failure
[ERROR]
/git/error-prone/core/src/main/java/com/google/errorprone/refaster/LocalVarBinding.java:[35,40]
';' expected
[ERROR]
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
'-e' switch
[ERROR] Re-run Maven using the '-X' switch to enable verbose output
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR]   mvn [args] -r


On Tue, 21 Feb 2023 at 01:13, Elliotte Rusty Harold 
wrote:

> On Mon, Feb 20, 2023 at 10:56 PM Romain Manni-Bucau
>  wrote:
> >
> > Do you want to make maven output only SUCCESS or FAILURE? All default
> info
> > logs are close to these download logs in practise.
> >
>
> Not always, but it should be far less verbose than it is now. It is an
> oft forgotten principle of TDD that passing tests generate no output.
> Maven fails that badly.
>
> Failures should indeed generate more output. However, the only helpful
> output is the output that points to the actual failure. Page after
> page of repetitive log junk only serves to obscure the true cause. It
> is not merely unhelpful. It actively hinders devs from finding
> problems.
>
> For example, a compile error should be reported with a clear message
> and the line, column, and file where the failure occurred. The message
> should be clear and actionable. But when I'm trying to figure out
> where a missing semicolon is, I really do not need to know every last
> artifact Maven downloaded, how big it is, and how long it took to
> download. I certainly don't need to get that information twice per
> artifact.
>
> --
> 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
>
>

Re: And while I'm on the subject of logging

Le mar. 21 févr. 2023 à 00:13, Elliotte Rusty Harold  a
écrit :

> On Mon, Feb 20, 2023 at 10:56 PM Romain Manni-Bucau
>  wrote:
> >
> > Do you want to make maven output only SUCCESS or FAILURE? All default
> info
> > logs are close to these download logs in practise.
> >
>
> Not always, but it should be far less verbose than it is now. It is an
> oft forgotten principle of TDD that passing tests generate no output.
> Maven fails that badly.
>

until feature is a log as in maven ;)

> Failures should indeed generate more output. However, the only helpful
> output is the output that points to the actual failure. Page after
> page of repetitive log junk only serves to obscure the true cause. It
> is not merely unhelpful. It actively hinders devs from finding
> problems.
>
> For example, a compile error should be reported with a clear message
> and the line, column, and file where the failure occurred. The message
> should be clear and actionable. But when I'm trying to figure out
> where a missing semicolon is, I really do not need to know every last
> artifact Maven downloaded, how big it is, and how long it took to
> download. I certainly don't need to get that information twice per
> artifact.
>

For a download error or an artifact error you do as much as the classpath
is key for the compiler plugin.

There is no silver bullet so depends your case and default should guide on
common errors.
Current logs helped several times, are only logged on downloads (almost
never on a well setup build) and we have flags to drop them at need so I'd
rather chase actual issues like interleaving or optimise the "ui" like mvnd
did than dropping info which has its public.
That said, if we move to loggers and use --logging-xxx cli opts we can make
it customizable with a user home default set of cli options which would
make everyone happy as everyone is with vi and a setup per person ;).

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

Re: And while I'm on the subject of logging

On Mon, Feb 20, 2023 at 10:56 PM Romain Manni-Bucau
 wrote:
>
> Do you want to make maven output only SUCCESS or FAILURE? All default info
> logs are close to these download logs in practise.
>

Not always, but it should be far less verbose than it is now. It is an
oft forgotten principle of TDD that passing tests generate no output.
Maven fails that badly.

Failures should indeed generate more output. However, the only helpful
output is the output that points to the actual failure. Page after
page of repetitive log junk only serves to obscure the true cause. It
is not merely unhelpful. It actively hinders devs from finding
problems.

For example, a compile error should be reported with a clear message
and the line, column, and file where the failure occurred. The message
should be clear and actionable. But when I'm trying to figure out
where a missing semicolon is, I really do not need to know every last
artifact Maven downloaded, how big it is, and how long it took to
download. I certainly don't need to get that information twice per
artifact.

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

Re: And while I'm on the subject of logging

Do you want to make maven output only SUCCESS or FAILURE? All default info
logs are close to these download logs in practise.

I think they are helpful, can agree with you on "not always" but having to
debug each time is worse than having to debug once from time to time so the
trade off is not bad.

That said while "enable-able" I agree it is ok but your reasoning is to
drop all logs and just use the exit status...not sure it is user friendly
at all.

Maven is like any software, it should communicate what it does to the user
without requiring all users to know the codebase IMHO so maybe just writing
an extension autoconfiguring the logs to what fits you and be it?

Anyway moving to a logger download logs really looks required whatever is
done and the interactive output can also help for human interactions.

Le lun. 20 févr. 2023 à 22:06, Elliotte Rusty Harold  a
écrit :

> On Mon, Feb 20, 2023 at 8:19 PM Romain Manni-Bucau
>  wrote:
>
> >
> > except that if you dont have it when you need (default) you have no
> > solution
>
> In my experience, about half the time when I do need a log message it
> still isn't there. I have to use a debugger, packet inspection, or
> some other technique to figure out what's going on. Programmers are
> very, very bad at predicting which log messages are likely to be
> useful. Even if it is present, it probably won't tell me most of what
> I need to know to understand and fix the problem. Log messages are not
> that helpful in practice.
>
> The reality is devs don't need almost all log messages almost all of
> the time. In those circumstances the sensible thing to do is to turn
> them off by default and require extra steps to turn them on for the
> 0.0001% of the cases when it might be helpful.
>
> --
> 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
>
>

Re: And while I'm on the subject of logging

On Mon, Feb 20, 2023 at 8:19 PM Romain Manni-Bucau
 wrote:

>
> except that if you dont have it when you need (default) you have no
> solution

In my experience, about half the time when I do need a log message it
still isn't there. I have to use a debugger, packet inspection, or
some other technique to figure out what's going on. Programmers are
very, very bad at predicting which log messages are likely to be
useful. Even if it is present, it probably won't tell me most of what
I need to know to understand and fix the problem. Log messages are not
that helpful in practice.

The reality is devs don't need almost all log messages almost all of
the time. In those circumstances the sensible thing to do is to turn
them off by default and require extra steps to turn them on for the
0.0001% of the cases when it might be helpful.

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

Re: And while I'm on the subject of logging

Le lun. 20 févr. 2023 à 19:51, Elliotte Rusty Harold  a
écrit :

> I don't believe anyone reads most of these messages most of the time.
> In fact, I'd venture that well more than 99% of them are never read by
> anyone. The default values should serve the common use case, not the
> exceptions. If an artifact fails to download, by all means log that
> fact, but don't hide that message amongst the 231 other artifacts that
> downloaded without a problem. It doesn't make sense to spew megabytes
> of logs that obscure real problems simply because someone thinks they
> might need to read one of these messages sometime.
>

except that if you dont have it when you need (default) you have no
solution



> In practice when something does go wrong, I find myself in one of two
> cases with roughly equal probability. Either the log info I need is
> somewhere in a very long stream of text that is challenging to search
> through or the information I need is in fact not logged at all and I
> have to use other methods to find out what's happening. Gratuitous,
> verbose logging has very little use.
>

It is why I said we will never get a good default for all cases:

* CI: you want it verbose to grep when needed
* CI bis: you want it not verbose cause output has limitations
* Human: you want it verbose cause it behaves weird (hanging repo for ex)
* Human: you want it quiet cause you just want success/error

At the end the usage of logger helps and maybe something like mvnd output
(terminal) where pending ops would stay printed until successfully done.

But hiding is not a solution IMHO, going more dynamic mixed with loggers
sound like a potential one to me.



> On Mon, Feb 20, 2023 at 3:02 PM Romain Manni-Bucau
>  wrote:
> >
> > Hi,
> >
> > I think the value of these lines are to know a download is pending (so
> > downloading line is key more than knowing it got downloaded which means
> > everything is fine).
> > The size has a lot value (in particular on CI) because some builds will
> > download huge artifacts (not detailling to avoid trolls but I'm sure you
> > can think of some build) and seeing you download 200M multiple times can
> be
> > a warning and explain why CI is unlikely to answer faster than checking
> > your local (sometimes empty if not your project and you just help). It
> also
> > helps to understand why it takes so long.
> >
> > So think we really have 2 steps:
> >
> > 1. make it all fully configurable (guess we all want to avoid any new CLI
> > option for such a thing and just use logger and --logging-level?)
> > 2. define the default: here I think we should be iso of today state or go
> > to something like "downloading..." for the *phase* (not per artifact) and
> > nothing more if we want the default to be less verbose
> >
> > Hope it makes sense.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le lun. 20 févr. 2023 à 15:53, Christoph Läubrich 
> a
> > écrit :
> >
> > > Maybe then one would remove that logging at all, and use different
> > > "logging plugin extensions" :-)
> > >
> > > Am 20.02.23 um 15:50 schrieb Enrico Olivelli:
> > > > Sometimes it is helpful to see that kind of logging when you run on
> CI
> > > > and you are troubleshooting why the build is slow.
> > > > In that case it would be useful to log only in the case that the
> > > > download took more than X seconds or the speed was too low (then it
> > > > would become debatable the default values for the thresholds...)
> > > >
> > > > my 2 cents
> > > >
> > > > Enrico
> > > >
> > > > Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich
> > > >  ha scritto:
> > > >>
> > > >> Well you can just reduce it to a single '.' who cares WHAT is
> download
> > > >> and where it is placed and from where... now put a line break after
> say
> > > >> 50 dots
> > > >>
> > > >>
> > > >> Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
> > > >>> Howdy,
> > > >>>
> > > >>> completely agree, the default could be something along those lin

Re: And while I'm on the subject of logging

I don't believe anyone reads most of these messages most of the time.
In fact, I'd venture that well more than 99% of them are never read by
anyone. The default values should serve the common use case, not the
exceptions. If an artifact fails to download, by all means log that
fact, but don't hide that message amongst the 231 other artifacts that
downloaded without a problem. It doesn't make sense to spew megabytes
of logs that obscure real problems simply because someone thinks they
might need to read one of these messages sometime.

In practice when something does go wrong, I find myself in one of two
cases with roughly equal probability. Either the log info I need is
somewhere in a very long stream of text that is challenging to search
through or the information I need is in fact not logged at all and I
have to use other methods to find out what's happening. Gratuitous,
verbose logging has very little use.

On Mon, Feb 20, 2023 at 3:02 PM Romain Manni-Bucau
 wrote:
>
> Hi,
>
> I think the value of these lines are to know a download is pending (so
> downloading line is key more than knowing it got downloaded which means
> everything is fine).
> The size has a lot value (in particular on CI) because some builds will
> download huge artifacts (not detailling to avoid trolls but I'm sure you
> can think of some build) and seeing you download 200M multiple times can be
> a warning and explain why CI is unlikely to answer faster than checking
> your local (sometimes empty if not your project and you just help). It also
> helps to understand why it takes so long.
>
> So think we really have 2 steps:
>
> 1. make it all fully configurable (guess we all want to avoid any new CLI
> option for such a thing and just use logger and --logging-level?)
> 2. define the default: here I think we should be iso of today state or go
> to something like "downloading..." for the *phase* (not per artifact) and
> nothing more if we want the default to be less verbose
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le lun. 20 févr. 2023 à 15:53, Christoph Läubrich  a
> écrit :
>
> > Maybe then one would remove that logging at all, and use different
> > "logging plugin extensions" :-)
> >
> > Am 20.02.23 um 15:50 schrieb Enrico Olivelli:
> > > Sometimes it is helpful to see that kind of logging when you run on CI
> > > and you are troubleshooting why the build is slow.
> > > In that case it would be useful to log only in the case that the
> > > download took more than X seconds or the speed was too low (then it
> > > would become debatable the default values for the thresholds...)
> > >
> > > my 2 cents
> > >
> > > Enrico
> > >
> > > Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich
> > >  ha scritto:
> > >>
> > >> Well you can just reduce it to a single '.' who cares WHAT is download
> > >> and where it is placed and from where... now put a line break after say
> > >> 50 dots
> > >>
> > >>
> > >> Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
> > >>> Howdy,
> > >>>
> > >>> completely agree, the default could be something along those lines:
> > >>>
> > >>> [DL] central
> > >>>
> > https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> > >>>
> > >>> So something like
> > >>> [DL|UP] $repoId $artifactUrl
> > >>>
> > >>> Full URL is handy as one can click on it in Terminal.app. But
> > >>> redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
> > >>> down/arrow up?)
> > >>>
> > >>> T
> > >>>
> > >>> On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold <
> > elh...@ibiblio.org>
> > >>> wrote:
> > >>>
> > >>>> Typical log message in build:
> > >>>>
> > >>>> Downloaded from central:
> > >>>>
> > >>>>
> > https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> > >>>> (14 kB at 776 kB/s)
> > >>>>
> > >>&g

Re: And while I'm on the subject of logging

2023-02-20 Thread Delany

I care to be able to see what is downloaded, and it makes sense to see when
an attempt is started and when it succeeds.
I don't care how big it is (I can find that out myself) or how fast its
pulled down (meaningless since parallel downloads).
When I don't want to see it I manipulate the simple logger properties.
Delany


On Mon, 20 Feb 2023 at 16:46, Christoph Läubrich 
wrote:

> Well you can just reduce it to a single '.' who cares WHAT is download
> and where it is placed and from where... now put a line break after say
> 50 dots
>
>
> Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
> > Howdy,
> >
> > completely agree, the default could be something along those lines:
> >
> > [DL] central
> >
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >
> > So something like
> > [DL|UP] $repoId $artifactUrl
> >
> > Full URL is handy as one can click on it in Terminal.app. But
> > redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
> > down/arrow up?)
> >
> > T
> >
> > On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold <
> elh...@ibiblio.org>
> > wrote:
> >
> >> Typical log message in build:
> >>
> >> Downloaded from central:
> >>
> >>
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >> (14 kB at 776 kB/s)
> >>
> >> I have never, ever needed or wanted to know how fast a single artifact
> >> was downloaded. And in the extremely unlikely event  I cared how big
> >> it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
> >> 776 kB/s)?
> >>
> >> Maven log files today are often multiple megabytes. Many continuous
> >> integration Web UIs truncate them to a 1 MB or so. Any unread info we
> >> can remove to bring the size down is helpful, and also makes it much
> >> easier for devs to find the lines they actually care about.
> >>
> >> --
> >> 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
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: And while I'm on the subject of logging

Hi,

I think the value of these lines are to know a download is pending (so
downloading line is key more than knowing it got downloaded which means
everything is fine).
The size has a lot value (in particular on CI) because some builds will
download huge artifacts (not detailling to avoid trolls but I'm sure you
can think of some build) and seeing you download 200M multiple times can be
a warning and explain why CI is unlikely to answer faster than checking
your local (sometimes empty if not your project and you just help). It also
helps to understand why it takes so long.

So think we really have 2 steps:

1. make it all fully configurable (guess we all want to avoid any new CLI
option for such a thing and just use logger and --logging-level?)
2. define the default: here I think we should be iso of today state or go
to something like "downloading..." for the *phase* (not per artifact) and
nothing more if we want the default to be less verbose

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 20 févr. 2023 à 15:53, Christoph Läubrich  a
écrit :

> Maybe then one would remove that logging at all, and use different
> "logging plugin extensions" :-)
>
> Am 20.02.23 um 15:50 schrieb Enrico Olivelli:
> > Sometimes it is helpful to see that kind of logging when you run on CI
> > and you are troubleshooting why the build is slow.
> > In that case it would be useful to log only in the case that the
> > download took more than X seconds or the speed was too low (then it
> > would become debatable the default values for the thresholds...)
> >
> > my 2 cents
> >
> > Enrico
> >
> > Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich
> >  ha scritto:
> >>
> >> Well you can just reduce it to a single '.' who cares WHAT is download
> >> and where it is placed and from where... now put a line break after say
> >> 50 dots
> >>
> >>
> >> Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
> >>> Howdy,
> >>>
> >>> completely agree, the default could be something along those lines:
> >>>
> >>> [DL] central
> >>>
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >>>
> >>> So something like
> >>> [DL|UP] $repoId $artifactUrl
> >>>
> >>> Full URL is handy as one can click on it in Terminal.app. But
> >>> redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
> >>> down/arrow up?)
> >>>
> >>> T
> >>>
> >>> On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold <
> elh...@ibiblio.org>
> >>> wrote:
> >>>
> >>>> Typical log message in build:
> >>>>
> >>>> Downloaded from central:
> >>>>
> >>>>
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >>>> (14 kB at 776 kB/s)
> >>>>
> >>>> I have never, ever needed or wanted to know how fast a single artifact
> >>>> was downloaded. And in the extremely unlikely event  I cared how big
> >>>> it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
> >>>> 776 kB/s)?
> >>>>
> >>>> Maven log files today are often multiple megabytes. Many continuous
> >>>> integration Web UIs truncate them to a 1 MB or so. Any unread info we
> >>>> can remove to bring the size down is helpful, and also makes it much
> >>>> easier for devs to find the lines they actually care about.
> >>>>
> >>>> --
> >>>> 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
> >>>>
> >>>>
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: And while I'm on the subject of logging

2023-02-20 Thread Christoph Läubrich

Maybe then one would remove that logging at all, and use different 
"logging plugin extensions" :-)


Am 20.02.23 um 15:50 schrieb Enrico Olivelli:

Sometimes it is helpful to see that kind of logging when you run on CI
and you are troubleshooting why the build is slow.
In that case it would be useful to log only in the case that the
download took more than X seconds or the speed was too low (then it
would become debatable the default values for the thresholds...)

my 2 cents

Enrico

Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich
 ha scritto:


Well you can just reduce it to a single '.' who cares WHAT is download
and where it is placed and from where... now put a line break after say
50 dots


Am 20.02.23 um 15:42 schrieb Tamás Cservenák:

Howdy,

completely agree, the default could be something along those lines:

[DL] central
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom

So something like
[DL|UP] $repoId $artifactUrl

Full URL is handy as one can click on it in Terminal.app. But
redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
down/arrow up?)

T

On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold 
wrote:


Typical log message in build:

Downloaded from central:

https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
(14 kB at 776 kB/s)

I have never, ever needed or wanted to know how fast a single artifact
was downloaded. And in the extremely unlikely event  I cared how big
it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
776 kB/s)?

Maven log files today are often multiple megabytes. Many continuous
integration Web UIs truncate them to a 1 MB or so. Any unread info we
can remove to bring the size down is helpful, and also makes it much
easier for devs to find the lines they actually care about.

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






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



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



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

Re: And while I'm on the subject of logging

2023-02-20 Thread Enrico Olivelli

Sometimes it is helpful to see that kind of logging when you run on CI
and you are troubleshooting why the build is slow.
In that case it would be useful to log only in the case that the
download took more than X seconds or the speed was too low (then it
would become debatable the default values for the thresholds...)

my 2 cents

Enrico

Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich
 ha scritto:
>
> Well you can just reduce it to a single '.' who cares WHAT is download
> and where it is placed and from where... now put a line break after say
> 50 dots
>
>
> Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
> > Howdy,
> >
> > completely agree, the default could be something along those lines:
> >
> > [DL] central
> > https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >
> > So something like
> > [DL|UP] $repoId $artifactUrl
> >
> > Full URL is handy as one can click on it in Terminal.app. But
> > redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
> > down/arrow up?)
> >
> > T
> >
> > On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold 
> > wrote:
> >
> >> Typical log message in build:
> >>
> >> Downloaded from central:
> >>
> >> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >> (14 kB at 776 kB/s)
> >>
> >> I have never, ever needed or wanted to know how fast a single artifact
> >> was downloaded. And in the extremely unlikely event  I cared how big
> >> it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
> >> 776 kB/s)?
> >>
> >> Maven log files today are often multiple megabytes. Many continuous
> >> integration Web UIs truncate them to a 1 MB or so. Any unread info we
> >> can remove to bring the size down is helpful, and also makes it much
> >> easier for devs to find the lines they actually care about.
> >>
> >> --
> >> 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
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: And while I'm on the subject of logging

2023-02-20 Thread Christoph Läubrich

Well you can just reduce it to a single '.' who cares WHAT is download 
and where it is placed and from where... now put a line break after say 
50 dots



Am 20.02.23 um 15:42 schrieb Tamás Cservenák:

Howdy,

completely agree, the default could be something along those lines:

[DL] central
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom

So something like
[DL|UP] $repoId $artifactUrl

Full URL is handy as one can click on it in Terminal.app. But
redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
down/arrow up?)

T

On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold 
wrote:


Typical log message in build:

Downloaded from central:

https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
(14 kB at 776 kB/s)

I have never, ever needed or wanted to know how fast a single artifact
was downloaded. And in the extremely unlikely event  I cared how big
it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
776 kB/s)?

Maven log files today are often multiple megabytes. Many continuous
integration Web UIs truncate them to a 1 MB or so. Any unread info we
can remove to bring the size down is helpful, and also makes it much
easier for devs to find the lines they actually care about.

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






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

Re: And while I'm on the subject of logging

Howdy,

completely agree, the default could be something along those lines:

[DL] central
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom

So something like
[DL|UP] $repoId $artifactUrl

Full URL is handy as one can click on it in Terminal.app. But
redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
down/arrow up?)

T

On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold 
wrote:

> Typical log message in build:
>
> Downloaded from central:
>
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> (14 kB at 776 kB/s)
>
> I have never, ever needed or wanted to know how fast a single artifact
> was downloaded. And in the extremely unlikely event  I cared how big
> it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
> 776 kB/s)?
>
> Maven log files today are often multiple megabytes. Many continuous
> integration Web UIs truncate them to a 1 MB or so. Any unread info we
> can remove to bring the size down is helpful, and also makes it much
> easier for devs to find the lines they actually care about.
>
> --
> 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
>
>

And while I'm on the subject of logging

Typical log message in build:

Downloaded from central:
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
(14 kB at 776 kB/s)

I have never, ever needed or wanted to know how fast a single artifact
was downloaded. And in the extremely unlikely event  I cared how big
it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
776 kB/s)?

Maven log files today are often multiple megabytes. Many continuous
integration Web UIs truncate them to a 1 MB or so. Any unread info we
can remove to bring the size down is helpful, and also makes it much
easier for devs to find the lines they actually care about.

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

Re: Halve the logging

Ok, thanks for the clarification. As I mentioned on the PR, it is merely a
"technical demo" to see how it would look, nothing more.
The PR is intentionally marked as "experiment" and left as draft, is not
meant to be merged or anything like that.

T

On Mon, Feb 20, 2023 at 2:14 PM Romain Manni-Bucau 
wrote:

> There are two issues which can be technically solved by using a logger per
> transfer listener callback method (which will keep it stateless):
>
> * It uses System.out so if you use a logger override of the slf4j binding
> which does not use System.out but the fd directly then log lines and
> transfer lines can be merged and output becomes unreadable
> * It is not configurable per event
>
> If you switch all callbacks to a logger.getLogger(getClass().getName() +
> ".$eventName") then you configure the logger and both are solved :).
>
> Romain
>
> Le lun. 20 févr. 2023 à 14:02, Tamás Cservenák  a
> écrit :
>
> > Resolver TransferListener implementations are stateless (or ideally
> should
> > be), everything they need is in event.
> > Unsure what "interleaving" issue you mention, as now listener emits two
> > (mutually exclusive) events only:
> > - transfer succeeded
> > - transfer failed
> >
> > T
> >
> > On Mon, Feb 20, 2023 at 1:55 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Doesn't it move the issue to the "next event"? Guess it should be fully
> > > customizable or not at all.
> > > Also it keeps the logging interleaving issue - this is why the logger
> > > solution sounded neat to me.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 20 févr. 2023 à 13:22, Tamás Cservenák  a
> > > écrit :
> > >
> > > > Created this PR as "experiment":
> > > > https://github.com/apache/maven/pull/1003
> > > >
> > > > It will produce "nearly" the upcoming Maven 3.9.1 and has a dirty
> hack:
> > > > -Dmaven.resolver.transfer.logging=full(as before)|half(the new
> default)
> > > >
> > > > As expected, one IT fails that asserts the "DownloadING" log line
> that
> > > this
> > > > Pr removes.
> > > >
> > > > build it, test drive it.
> > > >
> > > > Personally, I do like this new lighter output
> > > >
> > > > Thanks
> > > > T
> > > >
> > > > On Sun, Feb 19, 2023 at 9:21 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Maybe we should just move the console listener to a logger usage
> with
> > > > this
> > > > > pattern $classname.event, this way configuring the loggers enables
> > any
> > > > > customization and we dont get fishy console outputs too depending
> the
> > > > slf4j
> > > > > binding.
> > > > >
> > > > > Le dim. 19 févr. 2023 à 20:57, Benjamin Marwell <
> bmarw...@apache.org
> > >
> > > a
> > > > > écrit :
> > > > >
> > > > > > Sadly, --ntp also disables upload progress and ANY information
> > > > associated
> > > > > > with this.
> > > > > > Maybe it would be beneficial to have an option for that.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sun, 19 Feb 2023, 18:26 Michael Osipov, 
> > > > wrote:
> > > > > >
> > > > > > > Am 2023-02-19 um 18:17 schrieb Romain Manni-Bucau:
> > > > > > > > Not sure we can find an agreement on this topic, both
> opinions
> > > are
> > > > > very
> > > > > > > > valid and depends the persona/case so let's keep our default
> > > while
> > > > it
> > > > > > is
> > > > > > > > customizable easily it is fine IMHO.
> > > > > > >
> > > > > > > Good point, I could imagine that one could introduce
> > > > > --transfer-progress
> > > > > > > , similar Tamás did with Resolver transports.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Halve the logging

There are two issues which can be technically solved by using a logger per
transfer listener callback method (which will keep it stateless):

* It uses System.out so if you use a logger override of the slf4j binding
which does not use System.out but the fd directly then log lines and
transfer lines can be merged and output becomes unreadable
* It is not configurable per event

If you switch all callbacks to a logger.getLogger(getClass().getName() +
".$eventName") then you configure the logger and both are solved :).

Romain

Le lun. 20 févr. 2023 à 14:02, Tamás Cservenák  a
écrit :

> Resolver TransferListener implementations are stateless (or ideally should
> be), everything they need is in event.
> Unsure what "interleaving" issue you mention, as now listener emits two
> (mutually exclusive) events only:
> - transfer succeeded
> - transfer failed
>
> T
>
> On Mon, Feb 20, 2023 at 1:55 PM Romain Manni-Bucau 
> wrote:
>
> > Hi,
> >
> > Doesn't it move the issue to the "next event"? Guess it should be fully
> > customizable or not at all.
> > Also it keeps the logging interleaving issue - this is why the logger
> > solution sounded neat to me.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 20 févr. 2023 à 13:22, Tamás Cservenák  a
> > écrit :
> >
> > > Created this PR as "experiment":
> > > https://github.com/apache/maven/pull/1003
> > >
> > > It will produce "nearly" the upcoming Maven 3.9.1 and has a dirty hack:
> > > -Dmaven.resolver.transfer.logging=full(as before)|half(the new default)
> > >
> > > As expected, one IT fails that asserts the "DownloadING" log line that
> > this
> > > Pr removes.
> > >
> > > build it, test drive it.
> > >
> > > Personally, I do like this new lighter output
> > >
> > > Thanks
> > > T
> > >
> > > On Sun, Feb 19, 2023 at 9:21 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Maybe we should just move the console listener to a logger usage with
> > > this
> > > > pattern $classname.event, this way configuring the loggers enables
> any
> > > > customization and we dont get fishy console outputs too depending the
> > > slf4j
> > > > binding.
> > > >
> > > > Le dim. 19 févr. 2023 à 20:57, Benjamin Marwell  >
> > a
> > > > écrit :
> > > >
> > > > > Sadly, --ntp also disables upload progress and ANY information
> > > associated
> > > > > with this.
> > > > > Maybe it would be beneficial to have an option for that.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sun, 19 Feb 2023, 18:26 Michael Osipov, 
> > > wrote:
> > > > >
> > > > > > Am 2023-02-19 um 18:17 schrieb Romain Manni-Bucau:
> > > > > > > Not sure we can find an agreement on this topic, both opinions
> > are
> > > > very
> > > > > > > valid and depends the persona/case so let's keep our default
> > while
> > > it
> > > > > is
> > > > > > > customizable easily it is fine IMHO.
> > > > > >
> > > > > > Good point, I could imagine that one could introduce
> > > > --transfer-progress
> > > > > > , similar Tamás did with Resolver transports.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Halve the logging

Resolver TransferListener implementations are stateless (or ideally should
be), everything they need is in event.
Unsure what "interleaving" issue you mention, as now listener emits two
(mutually exclusive) events only:
- transfer succeeded
- transfer failed

T

On Mon, Feb 20, 2023 at 1:55 PM Romain Manni-Bucau 
wrote:

> Hi,
>
> Doesn't it move the issue to the "next event"? Guess it should be fully
> customizable or not at all.
> Also it keeps the logging interleaving issue - this is why the logger
> solution sounded neat to me.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 20 févr. 2023 à 13:22, Tamás Cservenák  a
> écrit :
>
> > Created this PR as "experiment":
> > https://github.com/apache/maven/pull/1003
> >
> > It will produce "nearly" the upcoming Maven 3.9.1 and has a dirty hack:
> > -Dmaven.resolver.transfer.logging=full(as before)|half(the new default)
> >
> > As expected, one IT fails that asserts the "DownloadING" log line that
> this
> > Pr removes.
> >
> > build it, test drive it.
> >
> > Personally, I do like this new lighter output
> >
> > Thanks
> > T
> >
> > On Sun, Feb 19, 2023 at 9:21 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Maybe we should just move the console listener to a logger usage with
> > this
> > > pattern $classname.event, this way configuring the loggers enables any
> > > customization and we dont get fishy console outputs too depending the
> > slf4j
> > > binding.
> > >
> > > Le dim. 19 févr. 2023 à 20:57, Benjamin Marwell 
> a
> > > écrit :
> > >
> > > > Sadly, --ntp also disables upload progress and ANY information
> > associated
> > > > with this.
> > > > Maybe it would be beneficial to have an option for that.
> > > >
> > > >
> > > >
> > > >
> > > > On Sun, 19 Feb 2023, 18:26 Michael Osipov, 
> > wrote:
> > > >
> > > > > Am 2023-02-19 um 18:17 schrieb Romain Manni-Bucau:
> > > > > > Not sure we can find an agreement on this topic, both opinions
> are
> > > very
> > > > > > valid and depends the persona/case so let's keep our default
> while
> > it
> > > > is
> > > > > > customizable easily it is fine IMHO.
> > > > >
> > > > > Good point, I could imagine that one could introduce
> > > --transfer-progress
> > > > > , similar Tamás did with Resolver transports.
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Halve the logging

Hi,

Doesn't it move the issue to the "next event"? Guess it should be fully
customizable or not at all.
Also it keeps the logging interleaving issue - this is why the logger
solution sounded neat to me.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 20 févr. 2023 à 13:22, Tamás Cservenák  a
écrit :

> Created this PR as "experiment":
> https://github.com/apache/maven/pull/1003
>
> It will produce "nearly" the upcoming Maven 3.9.1 and has a dirty hack:
> -Dmaven.resolver.transfer.logging=full(as before)|half(the new default)
>
> As expected, one IT fails that asserts the "DownloadING" log line that this
> Pr removes.
>
> build it, test drive it.
>
> Personally, I do like this new lighter output
>
> Thanks
> T
>
> On Sun, Feb 19, 2023 at 9:21 PM Romain Manni-Bucau 
> wrote:
>
> > Maybe we should just move the console listener to a logger usage with
> this
> > pattern $classname.event, this way configuring the loggers enables any
> > customization and we dont get fishy console outputs too depending the
> slf4j
> > binding.
> >
> > Le dim. 19 févr. 2023 à 20:57, Benjamin Marwell  a
> > écrit :
> >
> > > Sadly, --ntp also disables upload progress and ANY information
> associated
> > > with this.
> > > Maybe it would be beneficial to have an option for that.
> > >
> > >
> > >
> > >
> > > On Sun, 19 Feb 2023, 18:26 Michael Osipov, 
> wrote:
> > >
> > > > Am 2023-02-19 um 18:17 schrieb Romain Manni-Bucau:
> > > > > Not sure we can find an agreement on this topic, both opinions are
> > very
> > > > > valid and depends the persona/case so let's keep our default while
> it
> > > is
> > > > > customizable easily it is fine IMHO.
> > > >
> > > > Good point, I could imagine that one could introduce
> > --transfer-progress
> > > > , similar Tamás did with Resolver transports.
> > > >
> > > >
> > >
> >
>

Re: Halve the logging

Created this PR as "experiment":
https://github.com/apache/maven/pull/1003

It will produce "nearly" the upcoming Maven 3.9.1 and has a dirty hack:
-Dmaven.resolver.transfer.logging=full(as before)|half(the new default)

As expected, one IT fails that asserts the "DownloadING" log line that this
Pr removes.

build it, test drive it.

Personally, I do like this new lighter output

Thanks
T

On Sun, Feb 19, 2023 at 9:21 PM Romain Manni-Bucau 
wrote:

> Maybe we should just move the console listener to a logger usage with this
> pattern $classname.event, this way configuring the loggers enables any
> customization and we dont get fishy console outputs too depending the slf4j
> binding.
>
> Le dim. 19 févr. 2023 à 20:57, Benjamin Marwell  a
> écrit :
>
> > Sadly, --ntp also disables upload progress and ANY information associated
> > with this.
> > Maybe it would be beneficial to have an option for that.
> >
> >
> >
> >
> > On Sun, 19 Feb 2023, 18:26 Michael Osipov,  wrote:
> >
> > > Am 2023-02-19 um 18:17 schrieb Romain Manni-Bucau:
> > > > Not sure we can find an agreement on this topic, both opinions are
> very
> > > > valid and depends the persona/case so let's keep our default while it
> > is
> > > > customizable easily it is fine IMHO.
> > >
> > > Good point, I could imagine that one could introduce
> --transfer-progress
> > > , similar Tamás did with Resolver transports.
> > >
> > >
> >
>

Re: Halve the logging

2023-02-19 Thread Romain Manni-Bucau

Maybe we should just move the console listener to a logger usage with this
pattern $classname.event, this way configuring the loggers enables any
customization and we dont get fishy console outputs too depending the slf4j
binding.

Le dim. 19 févr. 2023 à 20:57, Benjamin Marwell  a
écrit :

> Sadly, --ntp also disables upload progress and ANY information associated
> with this.
> Maybe it would be beneficial to have an option for that.
>
>
>
>
> On Sun, 19 Feb 2023, 18:26 Michael Osipov,  wrote:
>
> > Am 2023-02-19 um 18:17 schrieb Romain Manni-Bucau:
> > > Not sure we can find an agreement on this topic, both opinions are very
> > > valid and depends the persona/case so let's keep our default while it
> is
> > > customizable easily it is fine IMHO.
> >
> > Good point, I could imagine that one could introduce --transfer-progress
> > , similar Tamás did with Resolver transports.
> >
> >
>

Re: Halve the logging

2023-02-19 Thread Benjamin Marwell

Sadly, --ntp also disables upload progress and ANY information associated
with this.
Maybe it would be beneficial to have an option for that.




On Sun, 19 Feb 2023, 18:26 Michael Osipov,  wrote:

> Am 2023-02-19 um 18:17 schrieb Romain Manni-Bucau:
> > Not sure we can find an agreement on this topic, both opinions are very
> > valid and depends the persona/case so let's keep our default while it is
> > customizable easily it is fine IMHO.
>
> Good point, I could imagine that one could introduce --transfer-progress
> , similar Tamás did with Resolver transports.
>
>

Re: Halve the logging

2023-02-19 Thread Michael Osipov


Am 2023-02-19 um 18:17 schrieb Romain Manni-Bucau:

Not sure we can find an agreement on this topic, both opinions are very
valid and depends the persona/case so let's keep our default while it is
customizable easily it is fine IMHO.


Good point, I could imagine that one could introduce --transfer-progress 
, similar Tamás did with Resolver transports.

Re: Halve the logging

2023-02-19 Thread Romain Manni-Bucau

Not sure we can find an agreement on this topic, both opinions are very
valid and depends the persona/case so let's keep our default while it is
customizable easily it is fine IMHO.

Le dim. 19 févr. 2023 à 17:06, Elliotte Rusty Harold  a
écrit :

> On Sun, Feb 19, 2023 at 2:02 PM Michael Osipov 
> wrote:
>
> > Use -B or --no-transfer-progress. Cutting in half does not really work
> > unless you don't want to say that download has started and finished *or*
> > you provide a custom status listener. Consider that download starts, but
> > then fails. No way to track that.
> >
> >
>
> Sure there is. Just log a message that the download failed. As is,
> Maven spews far too much log junk making it very hard to find real
> problems. No output for non-error conditions should be the default
> behavior. But this example is especially egregious.
>
> --
> 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
>
>

Re: Halve the logging

2023-02-19 Thread Elliotte Rusty Harold

On Sun, Feb 19, 2023 at 2:02 PM Michael Osipov  wrote:

> Use -B or --no-transfer-progress. Cutting in half does not really work
> unless you don't want to say that download has started and finished *or*
> you provide a custom status listener. Consider that download starts, but
> then fails. No way to track that.
>
>

Sure there is. Just log a message that the download failed. As is,
Maven spews far too much log junk making it very hard to find real
problems. No output for non-error conditions should be the default
behavior. But this example is especially egregious.

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

Re: Halve the logging

2023-02-19 Thread Gary Gregory

Yeah, this is tricky IMO because I would rather know that something has
started and is taking a long time rather than staring at an apparently hung
console.

I think it is fine as it is now and --no-transfer-progress is helpful and
also -ntp work the same? AFK.

Gary

Gary

On Sun, Feb 19, 2023, 09:13 Tamás Cservenák  wrote:

> This is resolver, but the logging listener is provided by maven.
>
> I'd +1 for this, as message can be "Downloaded" or "Failed to
> download..." and imo line for starting of download is chatty, really not
> needed.
>
> T
>
> On Sun, Feb 19, 2023, 14:59 Elliotte Rusty Harold 
> wrote:
>
> > Typical log message in build:
> >
> > Downloading from central:
> >
> >
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> > Downloaded from central:
> >
> >
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> > (14 kB at 776 kB/s)
> >
> > Which plugin does this come from? Could we kill one of these messages
> > to cut the number of log line junk in half?
> >
> > --
> > 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
> >
> >
>

Re: Halve the logging

2023-02-19 Thread Tamás Cservenák

This is resolver, but the logging listener is provided by maven.

I'd +1 for this, as message can be "Downloaded" or "Failed to
download..." and imo line for starting of download is chatty, really not
needed.

T

On Sun, Feb 19, 2023, 14:59 Elliotte Rusty Harold 
wrote:

> Typical log message in build:
>
> Downloading from central:
>
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> Downloaded from central:
>
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> (14 kB at 776 kB/s)
>
> Which plugin does this come from? Could we kill one of these messages
> to cut the number of log line junk in half?
>
> --
> 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
>
>

Re: Halve the logging

2023-02-19 Thread Michael Osipov


Am 2023-02-19 um 14:58 schrieb Elliotte Rusty Harold:

Typical log message in build:

Downloading from central:
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
(14 kB at 776 kB/s)

Which plugin does this come from? Could we kill one of these messages
to cut the number of log line junk in half?


Use -B or --no-transfer-progress. Cutting in half does not really work 
unless you don't want to say that download has started and finished *or* 
you provide a custom status listener. Consider that download starts, but 
then fails. No way to track that.



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

Halve the logging

2023-02-19 Thread Elliotte Rusty Harold

Typical log message in build:

Downloading from central:
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
(14 kB at 776 kB/s)

Which plugin does this come from? Could we kill one of these messages
to cut the number of log line junk in half?

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

Re: Logging in Maven Plugins - Bridging

2022-11-06 Thread Romain Manni-Bucau

Ok, think the thread starts to fork (;)).

On the "is JUL a bad API" point: to day it is close to concurrent and
likely equivalent on a pure technical point of view - keep in mind we now
have supplier which makes {} legacy and worse than concatenation most of
the times. Only thing it misses is probably NDC/MDC but in current
ascyn/reactive world it sounds like a good thing - it is too often broken
IMHO. Rest is biaised opinion - for both sides - since API are strictly
equivalent *technically* as of today.

Back to the original topic: as discussed multiple times in other thread, as
soon as maven leaks any 3rd party library we get troubles so even for
logging the rule of thumb should probably be to not leak anything else than
a controlled or JRE api which means for logging org.apache.maven.api.log.*
or JUL.
Once again for internals we can get debates but seems there had been a
local consensus about slf4j years ago so let's keep it but try to drop the
export from core/extensions.xml for maven 4 to stick to previous rule since
we can't do it for v3.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

Le dim. 6 nov. 2022 à 09:12, Mark Derricutt  a écrit :

>  On 6/11/2022 at 8:48:28 PM, Ralph Goers 
> wrote:
>
> > But the biggest problems with JUL include requiring everything being
> > wrapped with isEnabled type methods to avoid logging overhead
>
>
> I believe that was one of things addressed in the Flogger benefits - with
> their API using LOG.atDebug()... or LOG.atInfo()...
> that when not at the appropriate level, they can return a NoOpLogger which
> just does nothing, which avoids any over head formatting when logging (
> unless you do nasty string concatenation I guess ).
>
> Still flawed slightly IMHO tho.
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>

Re: Logging in Maven Plugins - Bridging

2022-11-06 Thread Mark Derricutt

 On 6/11/2022 at 8:48:28 PM, Ralph Goers  wrote:

> But the biggest problems with JUL include requiring everything being
> wrapped with isEnabled type methods to avoid logging overhead

I believe that was one of things addressed in the Flogger benefits - with
their API using LOG.atDebug()... or LOG.atInfo()...
that when not at the appropriate level, they can return a NoOpLogger which
just does nothing, which avoids any over head formatting when logging (
unless you do nasty string concatenation I guess ).

Still flawed slightly IMHO tho.

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Logging in Maven Plugins - Bridging

2022-11-06 Thread Ralph Goers

Yes, I am aware of Flogger. Both the Log4j and SLF4J APIs now also have 
fluent methods for those that prefer them. But the biggest problems with JUL 
include requiring everything being wrapped with isEnabled type methods to 
avoid logging overhead, an extremely limited set of Handlers, extremely 
limited filtering capabilities and finally, the terrible way it binds the 
logging 
implementation to the API. Although Log4j provides the documented way 
of bridging from JUL to it most people can’t use it because JUL typically 
initializes and binds to the JDK implementation before log4j can set the 
system property and they do not want to rely on having to manually set it.
The alternative approach of having a handler that routes to another 
logging framework is a hack and almost inevitably results in some 
performance loss.

Ralph

> On Nov 6, 2022, at 12:36 AM, Mark Derricutt  wrote:
> 
> On 6/11/2022 at 8:31:45 PM, Ralph Goers  wrote:
> 
>> I can absolutely guarantee you that if Google is actually using JUL that
>> they
>> have written plenty of their own code on top of it since JUL is woefully
>> incomplete.
> 
> 
> Google came up with Flogger - their fluent logging API that wraps JUL ( and
> now has pluggable backends ) but doesn’t seem to have any any updates for
> awhile: https://google.github.io/flogger/
> 
> The benefits page ( https://google.github.io/flogger/benefits ) is quite
> compelling, tho I find the API a bit cumbersome.
> 
> Mark
> 
> -- 
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree

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

Re: Logging in Maven Plugins - Bridging

2022-11-06 Thread Mark Derricutt

 On 6/11/2022 at 8:31:45 PM, Ralph Goers  wrote:

> I can absolutely guarantee you that if Google is actually using JUL that
> they
> have written plenty of their own code on top of it since JUL is woefully
> incomplete.


Google came up with Flogger - their fluent logging API that wraps JUL ( and
now has pluggable backends ) but doesn’t seem to have any any updates for
awhile: https://google.github.io/flogger/

The benefits page ( https://google.github.io/flogger/benefits ) is quite
compelling, tho I find the API a bit cumbersome.

Mark

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Logging in Maven Plugins - Bridging

2022-11-06 Thread Ralph Goers

> On Nov 5, 2022, at 6:08 AM, Elliotte Rusty Harold  wrote:
> 
> After log4shell last year, I no longer have any patience for third
> party logging libraries, full stop.
> 
> IMO logging should be done through java.util.logging, nothing else.
> This is fully functional since Java 1.4 twenty years ago. Log4j,
> slf4j, plexus-logging, etc. are all efforts to solve a problem we
> don't have any more. They are not needed and they introduce dependency
> problems and security issues.

Wow. I sure hope you mean this in the context of Maven only. JUL is the 
absolute worst API and implementation the JDK developers could have come 
up with. I have it on good authority that Ceki (the original author of Log4j 1 
and 
SLF4J) was consulted before JUL was added to JDK 1.4 but they pretty much 
ignored everything he told them. They have never enhanced it - other than to 
implement platform logging to avoid problems using JUL internally.

> 
> For one example, Google has used java.util.logging exclusively in all
> its internal Java code since at least 2008 and never needed anything
> more. This is a matter of policy inside Google, and as a result of
> this log4shell was close to a non-event for one of the largest Java
> shops on the planet. It wasn't a complete non-event only because of
> third party libraries that depended on log4j and open source projects
> that weren't quite as strict about following Google rules.

I can absolutely guarantee you that if Google is actually using JUL that they 
have written plenty of their own code on top of it since JUL is woefully 
incomplete.

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

Re: Logging in Maven Plugins - Bridging

2022-11-05 Thread Slawomir Jaranowski

Please take in consider that this topic is not about
- changing logging in Maven ecosystem,
- using or not third party library

If you feel that is needed  please start a separate thread about it.


sob., 5 lis 2022 o 19:34 Elliotte Rusty Harold 
napisał(a):

> You're right that I might as well be talking about all third party
> libraries. In fact, I've said exactly that elsewhere, most recently at
> ApacheCon a month ago and also here:
>
> https://jlbp.dev/JLBP-1
>
> The difference is only that we really, really don't need to take the
> risk for logging libraries when the JDK provides a perfectly good
> option with reliable maintainers (i.e. Oracle and the OpenJDK
> project).
>
> But of course I'm happy to get rid of other third party dependencies
> wherever feasible.
>
> On Sat, Nov 5, 2022 at 6:04 PM Gary Gregory 
> wrote:
> >
> > On Sat, Nov 5, 2022, 09:09 Elliotte Rusty Harold 
> wrote:
> >
> > > After log4shell last year, I no longer have any patience for third
> > > party logging libraries, full stop.
> > >
> >
> > Uh? CVEs have occurred in all types of libraries, there is nothing about
> > logging that makes it more CVE-prone. You might as well be talking about
> > all third party libraries.
> >
> > Gary
> >
> >
> > > IMO logging should be done through java.util.logging, nothing else.
> > > This is fully functional since Java 1.4 twenty years ago. Log4j,
> > > slf4j, plexus-logging, etc. are all efforts to solve a problem we
> > > don't have any more. They are not needed and they introduce dependency
> > > problems and security issues.
> > >
> > > For one example, Google has used java.util.logging exclusively in all
> > > its internal Java code since at least 2008 and never needed anything
> > > more. This is a matter of policy inside Google, and as a result of
> > > this log4shell was close to a non-event for one of the largest Java
> > > shops on the planet. It wasn't a complete non-event only because of
> > > third party libraries that depended on log4j and open source projects
> > > that weren't quite as strict about following Google rules.
> > >
> > > To the extent Maven and its plugins are currently dependent on SLF4J
> > > and others, this should be fixed. We should not continue down this
> > > path in any new or updated code. To be clear:
> > >
> > > 1. I am willing to do some of the work of ripping out old logging
> > > calls and replacing them with j.u.l.
> > >
> > > 2. It is OK to have mixed logging during a transition period.
> > >
> > > 3. It is OK if some log messages are lost or appear when they're not
> > > expected during a transition period. Logging is never critical
> > > functionality.
> > >
> > > What I am not willing to accept are dependency management problems and
> > > major security holes like log4shell due to optional, convenience
> > > functionality.
> > >
> > > On Fri, Nov 4, 2022 at 10:57 AM Slawomir Jaranowski
> > >  wrote:
> > > >
> > > > Hi,
> > > >
> > > > I want to start ( again :-) ) a discussion about logging in Maven
> > > plugins.
> > > >
> > > > First I agree that plugin developers should use logging methods
> provided
> > > by
> > > > Plugin api.
> > > >
> > > > But we can not expect plugin developers to write everything from
> scratch.
> > > > In many cases they may want to use an external library to do tasks
> needed
> > > > by the plugin.
> > > >
> > > > We don't have any control over what logging framework is used in the
> > > > external library used by plugin developers.
> > > >
> > > > We also maintain some libraries which can be used by plugin and also
> as
> > > > standalone in another project.
> > > > In such a case the question is - what logging we should use [1]?
> > > >
> > > > Last time I did a test, I use Java util logging from JDK in the Maven
> > > > plugin.
> > > > I see that Java util logging use default configuration, eg. we will
> have
> > > > two lines for one log event.
> > > > Even more options -q and -X have no effect for such a logger.
> > > >
> > > > One of the solution for such problem is using "Bridging" methods
> > > supported
> > > > by slf4j [2]
>

Re: Logging in Maven Plugins - Bridging

2022-11-05 Thread Elliotte Rusty Harold

You're right that I might as well be talking about all third party
libraries. In fact, I've said exactly that elsewhere, most recently at
ApacheCon a month ago and also here:

https://jlbp.dev/JLBP-1

The difference is only that we really, really don't need to take the
risk for logging libraries when the JDK provides a perfectly good
option with reliable maintainers (i.e. Oracle and the OpenJDK
project).

But of course I'm happy to get rid of other third party dependencies
wherever feasible.

On Sat, Nov 5, 2022 at 6:04 PM Gary Gregory  wrote:
>
> On Sat, Nov 5, 2022, 09:09 Elliotte Rusty Harold  wrote:
>
> > After log4shell last year, I no longer have any patience for third
> > party logging libraries, full stop.
> >
>
> Uh? CVEs have occurred in all types of libraries, there is nothing about
> logging that makes it more CVE-prone. You might as well be talking about
> all third party libraries.
>
> Gary
>
>
> > IMO logging should be done through java.util.logging, nothing else.
> > This is fully functional since Java 1.4 twenty years ago. Log4j,
> > slf4j, plexus-logging, etc. are all efforts to solve a problem we
> > don't have any more. They are not needed and they introduce dependency
> > problems and security issues.
> >
> > For one example, Google has used java.util.logging exclusively in all
> > its internal Java code since at least 2008 and never needed anything
> > more. This is a matter of policy inside Google, and as a result of
> > this log4shell was close to a non-event for one of the largest Java
> > shops on the planet. It wasn't a complete non-event only because of
> > third party libraries that depended on log4j and open source projects
> > that weren't quite as strict about following Google rules.
> >
> > To the extent Maven and its plugins are currently dependent on SLF4J
> > and others, this should be fixed. We should not continue down this
> > path in any new or updated code. To be clear:
> >
> > 1. I am willing to do some of the work of ripping out old logging
> > calls and replacing them with j.u.l.
> >
> > 2. It is OK to have mixed logging during a transition period.
> >
> > 3. It is OK if some log messages are lost or appear when they're not
> > expected during a transition period. Logging is never critical
> > functionality.
> >
> > What I am not willing to accept are dependency management problems and
> > major security holes like log4shell due to optional, convenience
> > functionality.
> >
> > On Fri, Nov 4, 2022 at 10:57 AM Slawomir Jaranowski
> >  wrote:
> > >
> > > Hi,
> > >
> > > I want to start ( again :-) ) a discussion about logging in Maven
> > plugins.
> > >
> > > First I agree that plugin developers should use logging methods provided
> > by
> > > Plugin api.
> > >
> > > But we can not expect plugin developers to write everything from scratch.
> > > In many cases they may want to use an external library to do tasks needed
> > > by the plugin.
> > >
> > > We don't have any control over what logging framework is used in the
> > > external library used by plugin developers.
> > >
> > > We also maintain some libraries which can be used by plugin and also as
> > > standalone in another project.
> > > In such a case the question is - what logging we should use [1]?
> > >
> > > Last time I did a test, I use Java util logging from JDK in the Maven
> > > plugin.
> > > I see that Java util logging use default configuration, eg. we will have
> > > two lines for one log event.
> > > Even more options -q and -X have no effect for such a logger.
> > >
> > > One of the solution for such problem is using "Bridging" methods
> > supported
> > > by slf4j [2]
> > > Probably all of existing and future logging frameworks can not be
> > covered -
> > > but most of common using will be.
> > >
> > > I hope that, even if we will want to change the logging framework used
> > > internally in Maven, we can also use the same method.
> > >
> > > [1] https://github.com/apache/maven-dependency-analyzer/pull/71
> > > [2] https://www.slf4j.org/legacy.html
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> >
> >
> >
> > --
> > 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

Re: Logging in Maven Plugins - Bridging

2022-11-05 Thread Romain Manni-Bucau

Le sam. 5 nov. 2022 à 19:03, Gary Gregory  a écrit :

> On Sat, Nov 5, 2022, 09:09 Elliotte Rusty Harold 
> wrote:
>
> > After log4shell last year, I no longer have any patience for third
> > party logging libraries, full stop.
> >
>
> Uh? CVEs have occurred in all types of libraries, there is nothing about
> logging that makes it more CVE-prone. You might as well be talking about
> all third party libraries.
>

Gale is different is cve comes from the jre or a lib. Jre is a must upgrade
anyway, a lib is additional work so JUL wins there by design.
Guess it was the point.



> Gary
>
>
> > IMO logging should be done through java.util.logging, nothing else.
> > This is fully functional since Java 1.4 twenty years ago. Log4j,
> > slf4j, plexus-logging, etc. are all efforts to solve a problem we
> > don't have any more. They are not needed and they introduce dependency
> > problems and security issues.
> >
> > For one example, Google has used java.util.logging exclusively in all
> > its internal Java code since at least 2008 and never needed anything
> > more. This is a matter of policy inside Google, and as a result of
> > this log4shell was close to a non-event for one of the largest Java
> > shops on the planet. It wasn't a complete non-event only because of
> > third party libraries that depended on log4j and open source projects
> > that weren't quite as strict about following Google rules.
> >
> > To the extent Maven and its plugins are currently dependent on SLF4J
> > and others, this should be fixed. We should not continue down this
> > path in any new or updated code. To be clear:
> >
> > 1. I am willing to do some of the work of ripping out old logging
> > calls and replacing them with j.u.l.
> >
> > 2. It is OK to have mixed logging during a transition period.
> >
> > 3. It is OK if some log messages are lost or appear when they're not
> > expected during a transition period. Logging is never critical
> > functionality.
> >
> > What I am not willing to accept are dependency management problems and
> > major security holes like log4shell due to optional, convenience
> > functionality.
> >
> > On Fri, Nov 4, 2022 at 10:57 AM Slawomir Jaranowski
> >  wrote:
> > >
> > > Hi,
> > >
> > > I want to start ( again :-) ) a discussion about logging in Maven
> > plugins.
> > >
> > > First I agree that plugin developers should use logging methods
> provided
> > by
> > > Plugin api.
> > >
> > > But we can not expect plugin developers to write everything from
> scratch.
> > > In many cases they may want to use an external library to do tasks
> needed
> > > by the plugin.
> > >
> > > We don't have any control over what logging framework is used in the
> > > external library used by plugin developers.
> > >
> > > We also maintain some libraries which can be used by plugin and also as
> > > standalone in another project.
> > > In such a case the question is - what logging we should use [1]?
> > >
> > > Last time I did a test, I use Java util logging from JDK in the Maven
> > > plugin.
> > > I see that Java util logging use default configuration, eg. we will
> have
> > > two lines for one log event.
> > > Even more options -q and -X have no effect for such a logger.
> > >
> > > One of the solution for such problem is using "Bridging" methods
> > supported
> > > by slf4j [2]
> > > Probably all of existing and future logging frameworks can not be
> > covered -
> > > but most of common using will be.
> > >
> > > I hope that, even if we will want to change the logging framework used
> > > internally in Maven, we can also use the same method.
> > >
> > > [1] https://github.com/apache/maven-dependency-analyzer/pull/71
> > > [2] https://www.slf4j.org/legacy.html
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> >
> >
> >
> > --
> > 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
> >
> >
>

Re: Logging in Maven Plugins - Bridging

2022-11-05 Thread Gary Gregory

On Sat, Nov 5, 2022, 09:09 Elliotte Rusty Harold  wrote:

> After log4shell last year, I no longer have any patience for third
> party logging libraries, full stop.
>

Uh? CVEs have occurred in all types of libraries, there is nothing about
logging that makes it more CVE-prone. You might as well be talking about
all third party libraries.

Gary


> IMO logging should be done through java.util.logging, nothing else.
> This is fully functional since Java 1.4 twenty years ago. Log4j,
> slf4j, plexus-logging, etc. are all efforts to solve a problem we
> don't have any more. They are not needed and they introduce dependency
> problems and security issues.
>
> For one example, Google has used java.util.logging exclusively in all
> its internal Java code since at least 2008 and never needed anything
> more. This is a matter of policy inside Google, and as a result of
> this log4shell was close to a non-event for one of the largest Java
> shops on the planet. It wasn't a complete non-event only because of
> third party libraries that depended on log4j and open source projects
> that weren't quite as strict about following Google rules.
>
> To the extent Maven and its plugins are currently dependent on SLF4J
> and others, this should be fixed. We should not continue down this
> path in any new or updated code. To be clear:
>
> 1. I am willing to do some of the work of ripping out old logging
> calls and replacing them with j.u.l.
>
> 2. It is OK to have mixed logging during a transition period.
>
> 3. It is OK if some log messages are lost or appear when they're not
> expected during a transition period. Logging is never critical
> functionality.
>
> What I am not willing to accept are dependency management problems and
> major security holes like log4shell due to optional, convenience
> functionality.
>
> On Fri, Nov 4, 2022 at 10:57 AM Slawomir Jaranowski
>  wrote:
> >
> > Hi,
> >
> > I want to start ( again :-) ) a discussion about logging in Maven
> plugins.
> >
> > First I agree that plugin developers should use logging methods provided
> by
> > Plugin api.
> >
> > But we can not expect plugin developers to write everything from scratch.
> > In many cases they may want to use an external library to do tasks needed
> > by the plugin.
> >
> > We don't have any control over what logging framework is used in the
> > external library used by plugin developers.
> >
> > We also maintain some libraries which can be used by plugin and also as
> > standalone in another project.
> > In such a case the question is - what logging we should use [1]?
> >
> > Last time I did a test, I use Java util logging from JDK in the Maven
> > plugin.
> > I see that Java util logging use default configuration, eg. we will have
> > two lines for one log event.
> > Even more options -q and -X have no effect for such a logger.
> >
> > One of the solution for such problem is using "Bridging" methods
> supported
> > by slf4j [2]
> > Probably all of existing and future logging frameworks can not be
> covered -
> > but most of common using will be.
> >
> > I hope that, even if we will want to change the logging framework used
> > internally in Maven, we can also use the same method.
> >
> > [1] https://github.com/apache/maven-dependency-analyzer/pull/71
> > [2] https://www.slf4j.org/legacy.html
> >
> >
> > --
> > Sławomir Jaranowski
>
>
>
> --
> 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
>
>

Re: Logging in Maven Plugins - Bridging

2022-11-05 Thread Elliotte Rusty Harold

After log4shell last year, I no longer have any patience for third
party logging libraries, full stop.

IMO logging should be done through java.util.logging, nothing else.
This is fully functional since Java 1.4 twenty years ago. Log4j,
slf4j, plexus-logging, etc. are all efforts to solve a problem we
don't have any more. They are not needed and they introduce dependency
problems and security issues.

For one example, Google has used java.util.logging exclusively in all
its internal Java code since at least 2008 and never needed anything
more. This is a matter of policy inside Google, and as a result of
this log4shell was close to a non-event for one of the largest Java
shops on the planet. It wasn't a complete non-event only because of
third party libraries that depended on log4j and open source projects
that weren't quite as strict about following Google rules.

To the extent Maven and its plugins are currently dependent on SLF4J
and others, this should be fixed. We should not continue down this
path in any new or updated code. To be clear:

1. I am willing to do some of the work of ripping out old logging
calls and replacing them with j.u.l.

2. It is OK to have mixed logging during a transition period.

3. It is OK if some log messages are lost or appear when they're not
expected during a transition period. Logging is never critical
functionality.

What I am not willing to accept are dependency management problems and
major security holes like log4shell due to optional, convenience
functionality.

On Fri, Nov 4, 2022 at 10:57 AM Slawomir Jaranowski
 wrote:
>
> Hi,
>
> I want to start ( again :-) ) a discussion about logging in Maven plugins.
>
> First I agree that plugin developers should use logging methods provided by
> Plugin api.
>
> But we can not expect plugin developers to write everything from scratch.
> In many cases they may want to use an external library to do tasks needed
> by the plugin.
>
> We don't have any control over what logging framework is used in the
> external library used by plugin developers.
>
> We also maintain some libraries which can be used by plugin and also as
> standalone in another project.
> In such a case the question is - what logging we should use [1]?
>
> Last time I did a test, I use Java util logging from JDK in the Maven
> plugin.
> I see that Java util logging use default configuration, eg. we will have
> two lines for one log event.
> Even more options -q and -X have no effect for such a logger.
>
> One of the solution for such problem is using "Bridging" methods supported
> by slf4j [2]
> Probably all of existing and future logging frameworks can not be covered -
> but most of common using will be.
>
> I hope that, even if we will want to change the logging framework used
> internally in Maven, we can also use the same method.
>
> [1] https://github.com/apache/maven-dependency-analyzer/pull/71
> [2] https://www.slf4j.org/legacy.html
>
>
> --
> Sławomir Jaranowski

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

Re: Logging in Maven Plugins - Bridging

2022-11-05 Thread Benjamin Marwell

> Maven Plugin code should use Plugin Api for logging purpose
> In shared libraries used by Maven and maintained by us - we will use
SLF4J directly

I asked to be allowed to put this on the logging site, but we never had
consensus of this. I agree  here, but ut really needs to get documented.
I saw dozens of plugins switching from Maven's logging API to slf4j
directly - which is probably not what you wanted.

But at least we now have it written down. 
I hope everyone agrees on this.
If so, let's make it official by updating the documentation.

- Ben

On Fri, 4 Nov 2022, 18:42 Slawomir Jaranowski, 
wrote:

> Once again thanks for feedback.
>
> In order to finish discussion and not return to this topic again I will try
> to update documentation about logging in Maven plugins ... so I see the
> message, as Tamás wrote
>
> - Maven core and ecosystem uses SLF4J.
> - Maven Plugin code should use Plugin Api for logging purpose
> - In shared libraries used by Maven and maintained by us - we will use
> SLF4J directly
>
> One case which I would like to discuss was when plugins use something other
> than SLF4J, directly or by using an external library.
> To support proper logging we need forward events to SLF4J.
>
> So I see two ways:
> 1. support forwarding log event from another library to SLF4J by Maven core
> itself
>
> 2. let responsibility of log event forwarding will be on Plugin developers
>
> Personally I'm for the second option - it is not a common case, so
> developers can do it if really needed.
>
> Finally should be documented and will be clear,  discussion will be
> finished.
>
>
> pt., 4 lis 2022 o 15:08 Romain Manni-Bucau 
> napisał(a):
>
> > > perfectly valid solution (classloader)
> >
> > This is a workaround any plugin developer hates to be honest.
> > Guillaume started to make the plugin ClassRealm more customizable, this
> can
> > be an option but still, means we don't leak slf4j.
> > I fully agree the issue is how we expose it to plugins and extensions
> since
> > for the core codebase we don't care which solution we use but it just
> moves
> > the choice to the later stage and lead the same solution.
> >
> > In terms of biggest issue I guess it is the ones people face, logging is
> a
> > common one, not sure others you have in mind but this one and classloader
> > are the two biggest from what I saw, rest are enhancements and nice to
> have
> > from my window.
> >
> > My 2cts indeed
> >
> > Le ven. 4 nov. 2022 à 15:00, Tamás Cservenák  a
> > écrit :
> >
> > > So, you see problems in some plugins (again, what is the ratio we speak
> > > about?)
> > > using some frameworks, and then you tell the perfectly valid solution
> > > (classloader)...
> > >
> > > And regarding slf4j, should I reiterate what Ceki repeated several
> times?
> > >
> > > Sorry, but these are non-issues IMHO.
> > >
> > > Or to rephrase: we have bigger issues to work on, and helping complex
> > > plugin
> > > writers by removing from them one single burden (to use custom
> > classloader,
> > > if must)
> > > is really a small benefit, compared to man hours spent on whole topic
> > > already.
> > >
> > > My 5c.
> > >
> > > T
> > >
> > > On Fri, Nov 4, 2022 at 1:58 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > wrote:
> > >
> > > > Le ven. 4 nov. 2022 à 13:17, Tamás Cservenák  a
> > > > écrit :
> > > >
> > > > > Howdy,
> > > > >
> > > > > Will we keep asking the same questions over and over again? Until
> we
> > > get
> > > > > the "wanted" answer?
> > > > >
> > > > > Maven core and ecosystem uses SLF4J API. Full stop.
> > > > >
> > > > > Just use SLF4J API, and you will get a pre-configured back-end as
> > well.
> > > > > Done.
> > > > >
> > > > > Now,. this story keeps popping up: "plugin developers using
> > > > framework"
> > > > > begs the question:
> > > > > what framework are we talking about? And how common is this story?
> > What
> > > > > percentage of Maven
> > > > > plugins USE a "framework"?
> > > > >
> > > >
> > > > All plugins with a dependency on slf4j are concerned and best ones
> use
> > > > workarounds (custom classloader instead of mojo one) others can be
> >

Re: Logging in Maven Plugins - Bridging

Agree for option (disagree it is not common but that's not important) just
because there is no real choice else we would need to handle all libraries
and all versions which is clearly a no go for me.

Just a side note on the shared code: fully agree until log is exposed in
the API and can be reused accross plugins.

Otherwise +1 for this compromise.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 4 nov. 2022 à 18:42, Slawomir Jaranowski  a
écrit :

> Once again thanks for feedback.
>
> In order to finish discussion and not return to this topic again I will try
> to update documentation about logging in Maven plugins ... so I see the
> message, as Tamás wrote
>
> - Maven core and ecosystem uses SLF4J.
> - Maven Plugin code should use Plugin Api for logging purpose
> - In shared libraries used by Maven and maintained by us - we will use
> SLF4J directly
>
> One case which I would like to discuss was when plugins use something other
> than SLF4J, directly or by using an external library.
> To support proper logging we need forward events to SLF4J.
>
> So I see two ways:
> 1. support forwarding log event from another library to SLF4J by Maven core
> itself
>
> 2. let responsibility of log event forwarding will be on Plugin developers
>
> Personally I'm for the second option - it is not a common case, so
> developers can do it if really needed.
>
> Finally should be documented and will be clear,  discussion will be
> finished.
>
>
> pt., 4 lis 2022 o 15:08 Romain Manni-Bucau 
> napisał(a):
>
> > > perfectly valid solution (classloader)
> >
> > This is a workaround any plugin developer hates to be honest.
> > Guillaume started to make the plugin ClassRealm more customizable, this
> can
> > be an option but still, means we don't leak slf4j.
> > I fully agree the issue is how we expose it to plugins and extensions
> since
> > for the core codebase we don't care which solution we use but it just
> moves
> > the choice to the later stage and lead the same solution.
> >
> > In terms of biggest issue I guess it is the ones people face, logging is
> a
> > common one, not sure others you have in mind but this one and classloader
> > are the two biggest from what I saw, rest are enhancements and nice to
> have
> > from my window.
> >
> > My 2cts indeed
> >
> > Le ven. 4 nov. 2022 à 15:00, Tamás Cservenák  a
> > écrit :
> >
> > > So, you see problems in some plugins (again, what is the ratio we speak
> > > about?)
> > > using some frameworks, and then you tell the perfectly valid solution
> > > (classloader)...
> > >
> > > And regarding slf4j, should I reiterate what Ceki repeated several
> times?
> > >
> > > Sorry, but these are non-issues IMHO.
> > >
> > > Or to rephrase: we have bigger issues to work on, and helping complex
> > > plugin
> > > writers by removing from them one single burden (to use custom
> > classloader,
> > > if must)
> > > is really a small benefit, compared to man hours spent on whole topic
> > > already.
> > >
> > > My 5c.
> > >
> > > T
> > >
> > > On Fri, Nov 4, 2022 at 1:58 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > wrote:
> > >
> > > > Le ven. 4 nov. 2022 à 13:17, Tamás Cservenák  a
> > > > écrit :
> > > >
> > > > > Howdy,
> > > > >
> > > > > Will we keep asking the same questions over and over again? Until
> we
> > > get
> > > > > the "wanted" answer?
> > > > >
> > > > > Maven core and ecosystem uses SLF4J API. Full stop.
> > > > >
> > > > > Just use SLF4J API, and you will get a pre-configured back-end as
> > well.
> > > > > Done.
> > > > >
> > > > > Now,. this story keeps popping up: "plugin developers using
> > > > framework"
> > > > > begs the question:
> > > > > what framework are we talking about? And how common is this story?
> > What
> > > > > percentage of Maven
> > > > > plugins USE a "framework"?
> > > > >
> > > >
> > > > All p

Re: Logging in Maven Plugins - Bridging

2022-11-04 Thread Slawomir Jaranowski

Once again thanks for feedback.

In order to finish discussion and not return to this topic again I will try
to update documentation about logging in Maven plugins ... so I see the
message, as Tamás wrote

- Maven core and ecosystem uses SLF4J.
- Maven Plugin code should use Plugin Api for logging purpose
- In shared libraries used by Maven and maintained by us - we will use
SLF4J directly

One case which I would like to discuss was when plugins use something other
than SLF4J, directly or by using an external library.
To support proper logging we need forward events to SLF4J.

So I see two ways:
1. support forwarding log event from another library to SLF4J by Maven core
itself

2. let responsibility of log event forwarding will be on Plugin developers

Personally I'm for the second option - it is not a common case, so
developers can do it if really needed.

Finally should be documented and will be clear,  discussion will be
finished.


pt., 4 lis 2022 o 15:08 Romain Manni-Bucau 
napisał(a):

> > perfectly valid solution (classloader)
>
> This is a workaround any plugin developer hates to be honest.
> Guillaume started to make the plugin ClassRealm more customizable, this can
> be an option but still, means we don't leak slf4j.
> I fully agree the issue is how we expose it to plugins and extensions since
> for the core codebase we don't care which solution we use but it just moves
> the choice to the later stage and lead the same solution.
>
> In terms of biggest issue I guess it is the ones people face, logging is a
> common one, not sure others you have in mind but this one and classloader
> are the two biggest from what I saw, rest are enhancements and nice to have
> from my window.
>
> My 2cts indeed
>
> Le ven. 4 nov. 2022 à 15:00, Tamás Cservenák  a
> écrit :
>
> > So, you see problems in some plugins (again, what is the ratio we speak
> > about?)
> > using some frameworks, and then you tell the perfectly valid solution
> > (classloader)...
> >
> > And regarding slf4j, should I reiterate what Ceki repeated several times?
> >
> > Sorry, but these are non-issues IMHO.
> >
> > Or to rephrase: we have bigger issues to work on, and helping complex
> > plugin
> > writers by removing from them one single burden (to use custom
> classloader,
> > if must)
> > is really a small benefit, compared to man hours spent on whole topic
> > already.
> >
> > My 5c.
> >
> > T
> >
> > On Fri, Nov 4, 2022 at 1:58 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > Le ven. 4 nov. 2022 à 13:17, Tamás Cservenák  a
> > > écrit :
> > >
> > > > Howdy,
> > > >
> > > > Will we keep asking the same questions over and over again? Until we
> > get
> > > > the "wanted" answer?
> > > >
> > > > Maven core and ecosystem uses SLF4J API. Full stop.
> > > >
> > > > Just use SLF4J API, and you will get a pre-configured back-end as
> well.
> > > > Done.
> > > >
> > > > Now,. this story keeps popping up: "plugin developers using
> > > framework"
> > > > begs the question:
> > > > what framework are we talking about? And how common is this story?
> What
> > > > percentage of Maven
> > > > plugins USE a "framework"?
> > > >
> > >
> > > All plugins with a dependency on slf4j are concerned and best ones use
> > > workarounds (custom classloader instead of mojo one) others can be
> broken
> > > by default (exec:java maven plugin needed a dedicated config for that
> > case
> > > for ex).
> > > To cite a few: tomee, spark, cxf, camel, openapi/swagger ones, plus all
> > the
> > > ones invovling user code with slf4j (most end *apps* included - you
> like
> > it
> > > or not like me ;)).
> > >
> > > Indeed the mojo copying a file will not be impacted but it is quite
> rare
> > > these days to not have a build with at least one of these plugins.
> > > We also have the big issue we reported years ago that we leak slf4j for
> > > mojo (maven-core/extensions.xml) so we enforce the slf4j version, API
> and
> > > public API whereas we have mojo designed to do what they need to do the
> > way
> > > they want.
> > > Exactly like we dropped cdi-api because it was breaking more than
> > helping,
> > > slf4j is at the same position - whatever its own quality when used
> > outside
> > > a pluggable system.
> > >
> > > So yes, leaking *any* not maven owned API is an issue, sl

Re: Logging in Maven Plugins - Bridging

> perfectly valid solution (classloader)

This is a workaround any plugin developer hates to be honest.
Guillaume started to make the plugin ClassRealm more customizable, this can
be an option but still, means we don't leak slf4j.
I fully agree the issue is how we expose it to plugins and extensions since
for the core codebase we don't care which solution we use but it just moves
the choice to the later stage and lead the same solution.

In terms of biggest issue I guess it is the ones people face, logging is a
common one, not sure others you have in mind but this one and classloader
are the two biggest from what I saw, rest are enhancements and nice to have
from my window.

My 2cts indeed

Le ven. 4 nov. 2022 à 15:00, Tamás Cservenák  a écrit :

> So, you see problems in some plugins (again, what is the ratio we speak
> about?)
> using some frameworks, and then you tell the perfectly valid solution
> (classloader)...
>
> And regarding slf4j, should I reiterate what Ceki repeated several times?
>
> Sorry, but these are non-issues IMHO.
>
> Or to rephrase: we have bigger issues to work on, and helping complex
> plugin
> writers by removing from them one single burden (to use custom classloader,
> if must)
> is really a small benefit, compared to man hours spent on whole topic
> already.
>
> My 5c.
>
> T
>
> On Fri, Nov 4, 2022 at 1:58 PM Romain Manni-Bucau 
> wrote:
>
> > Le ven. 4 nov. 2022 à 13:17, Tamás Cservenák  a
> > écrit :
> >
> > > Howdy,
> > >
> > > Will we keep asking the same questions over and over again? Until we
> get
> > > the "wanted" answer?
> > >
> > > Maven core and ecosystem uses SLF4J API. Full stop.
> > >
> > > Just use SLF4J API, and you will get a pre-configured back-end as well.
> > > Done.
> > >
> > > Now,. this story keeps popping up: "plugin developers using
> > framework"
> > > begs the question:
> > > what framework are we talking about? And how common is this story? What
> > > percentage of Maven
> > > plugins USE a "framework"?
> > >
> >
> > All plugins with a dependency on slf4j are concerned and best ones use
> > workarounds (custom classloader instead of mojo one) others can be broken
> > by default (exec:java maven plugin needed a dedicated config for that
> case
> > for ex).
> > To cite a few: tomee, spark, cxf, camel, openapi/swagger ones, plus all
> the
> > ones invovling user code with slf4j (most end *apps* included - you like
> it
> > or not like me ;)).
> >
> > Indeed the mojo copying a file will not be impacted but it is quite rare
> > these days to not have a build with at least one of these plugins.
> > We also have the big issue we reported years ago that we leak slf4j for
> > mojo (maven-core/extensions.xml) so we enforce the slf4j version, API and
> > public API whereas we have mojo designed to do what they need to do the
> way
> > they want.
> > Exactly like we dropped cdi-api because it was breaking more than
> helping,
> > slf4j is at the same position - whatever its own quality when used
> outside
> > a pluggable system.
> >
> > So yes, leaking *any* not maven owned API is an issue, slf4j is just
> ultra
> > visible due to its past adoption.
> >
> > If it helps, we got the same topic at tomee (with log4j1 at that time)
> and
> > the move to JUL was leading to the same kind of thread but after the
> change
> > we got way less logging issues and related bugs and not much complains,
> so
> > I think it was the right choice and since maven architecture hits the
> same
> > kind of pitfalls I think the same outcome would be beneficial.
> >
> >
> > >
> > > my 5 cents.
> > > T
> > >
> > > On Fri, Nov 4, 2022 at 11:56 AM Slawomir Jaranowski <
> > > s.jaranow...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I want to start ( again :-) ) a discussion about logging in Maven
> > > plugins.
> > > >
> > > > First I agree that plugin developers should use logging methods
> > provided
> > > by
> > > > Plugin api.
> > > >
> > > > But we can not expect plugin developers to write everything from
> > scratch.
> > > > In many cases they may want to use an external library to do tasks
> > needed
> > > > by the plugin.
> > > >
> > > > We don't have any control over what logging framework is used in the
> > > > external libra

Re: Logging in Maven Plugins - Bridging

2022-11-04 Thread Tamás Cservenák

So, you see problems in some plugins (again, what is the ratio we speak
about?)
using some frameworks, and then you tell the perfectly valid solution
(classloader)...

And regarding slf4j, should I reiterate what Ceki repeated several times?

Sorry, but these are non-issues IMHO.

Or to rephrase: we have bigger issues to work on, and helping complex plugin
writers by removing from them one single burden (to use custom classloader,
if must)
is really a small benefit, compared to man hours spent on whole topic
already.

My 5c.

T

On Fri, Nov 4, 2022 at 1:58 PM Romain Manni-Bucau 
wrote:

> Le ven. 4 nov. 2022 à 13:17, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > Will we keep asking the same questions over and over again? Until we get
> > the "wanted" answer?
> >
> > Maven core and ecosystem uses SLF4J API. Full stop.
> >
> > Just use SLF4J API, and you will get a pre-configured back-end as well.
> > Done.
> >
> > Now,. this story keeps popping up: "plugin developers using
> framework"
> > begs the question:
> > what framework are we talking about? And how common is this story? What
> > percentage of Maven
> > plugins USE a "framework"?
> >
>
> All plugins with a dependency on slf4j are concerned and best ones use
> workarounds (custom classloader instead of mojo one) others can be broken
> by default (exec:java maven plugin needed a dedicated config for that case
> for ex).
> To cite a few: tomee, spark, cxf, camel, openapi/swagger ones, plus all the
> ones invovling user code with slf4j (most end *apps* included - you like it
> or not like me ;)).
>
> Indeed the mojo copying a file will not be impacted but it is quite rare
> these days to not have a build with at least one of these plugins.
> We also have the big issue we reported years ago that we leak slf4j for
> mojo (maven-core/extensions.xml) so we enforce the slf4j version, API and
> public API whereas we have mojo designed to do what they need to do the way
> they want.
> Exactly like we dropped cdi-api because it was breaking more than helping,
> slf4j is at the same position - whatever its own quality when used outside
> a pluggable system.
>
> So yes, leaking *any* not maven owned API is an issue, slf4j is just ultra
> visible due to its past adoption.
>
> If it helps, we got the same topic at tomee (with log4j1 at that time) and
> the move to JUL was leading to the same kind of thread but after the change
> we got way less logging issues and related bugs and not much complains, so
> I think it was the right choice and since maven architecture hits the same
> kind of pitfalls I think the same outcome would be beneficial.
>
>
> >
> > my 5 cents.
> > T
> >
> > On Fri, Nov 4, 2022 at 11:56 AM Slawomir Jaranowski <
> > s.jaranow...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I want to start ( again :-) ) a discussion about logging in Maven
> > plugins.
> > >
> > > First I agree that plugin developers should use logging methods
> provided
> > by
> > > Plugin api.
> > >
> > > But we can not expect plugin developers to write everything from
> scratch.
> > > In many cases they may want to use an external library to do tasks
> needed
> > > by the plugin.
> > >
> > > We don't have any control over what logging framework is used in the
> > > external library used by plugin developers.
> > >
> > > We also maintain some libraries which can be used by plugin and also as
> > > standalone in another project.
> > > In such a case the question is - what logging we should use [1]?
> > >
> > > Last time I did a test, I use Java util logging from JDK in the Maven
> > > plugin.
> > > I see that Java util logging use default configuration, eg. we will
> have
> > > two lines for one log event.
> > > Even more options -q and -X have no effect for such a logger.
> > >
> > > One of the solution for such problem is using "Bridging" methods
> > supported
> > > by slf4j [2]
> > > Probably all of existing and future logging frameworks can not be
> > covered -
> > > but most of common using will be.
> > >
> > > I hope that, even if we will want to change the logging framework used
> > > internally in Maven, we can also use the same method.
> > >
> > > [1] https://github.com/apache/maven-dependency-analyzer/pull/71
> > > [2] https://www.slf4j.org/legacy.html
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>

Re: Logging in Maven Plugins - Bridging

Le ven. 4 nov. 2022 à 13:17, Tamás Cservenák  a écrit :

> Howdy,
>
> Will we keep asking the same questions over and over again? Until we get
> the "wanted" answer?
>
> Maven core and ecosystem uses SLF4J API. Full stop.
>
> Just use SLF4J API, and you will get a pre-configured back-end as well.
> Done.
>
> Now,. this story keeps popping up: "plugin developers using framework"
> begs the question:
> what framework are we talking about? And how common is this story? What
> percentage of Maven
> plugins USE a "framework"?
>

All plugins with a dependency on slf4j are concerned and best ones use
workarounds (custom classloader instead of mojo one) others can be broken
by default (exec:java maven plugin needed a dedicated config for that case
for ex).
To cite a few: tomee, spark, cxf, camel, openapi/swagger ones, plus all the
ones invovling user code with slf4j (most end *apps* included - you like it
or not like me ;)).

Indeed the mojo copying a file will not be impacted but it is quite rare
these days to not have a build with at least one of these plugins.
We also have the big issue we reported years ago that we leak slf4j for
mojo (maven-core/extensions.xml) so we enforce the slf4j version, API and
public API whereas we have mojo designed to do what they need to do the way
they want.
Exactly like we dropped cdi-api because it was breaking more than helping,
slf4j is at the same position - whatever its own quality when used outside
a pluggable system.

So yes, leaking *any* not maven owned API is an issue, slf4j is just ultra
visible due to its past adoption.

If it helps, we got the same topic at tomee (with log4j1 at that time) and
the move to JUL was leading to the same kind of thread but after the change
we got way less logging issues and related bugs and not much complains, so
I think it was the right choice and since maven architecture hits the same
kind of pitfalls I think the same outcome would be beneficial.

>
> my 5 cents.
> T
>
> On Fri, Nov 4, 2022 at 11:56 AM Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I want to start ( again :-) ) a discussion about logging in Maven
> plugins.
> >
> > First I agree that plugin developers should use logging methods provided
> by
> > Plugin api.
> >
> > But we can not expect plugin developers to write everything from scratch.
> > In many cases they may want to use an external library to do tasks needed
> > by the plugin.
> >
> > We don't have any control over what logging framework is used in the
> > external library used by plugin developers.
> >
> > We also maintain some libraries which can be used by plugin and also as
> > standalone in another project.
> > In such a case the question is - what logging we should use [1]?
> >
> > Last time I did a test, I use Java util logging from JDK in the Maven
> > plugin.
> > I see that Java util logging use default configuration, eg. we will have
> > two lines for one log event.
> > Even more options -q and -X have no effect for such a logger.
> >
> > One of the solution for such problem is using "Bridging" methods
> supported
> > by slf4j [2]
> > Probably all of existing and future logging frameworks can not be
> covered -
> > but most of common using will be.
> >
> > I hope that, even if we will want to change the logging framework used
> > internally in Maven, we can also use the same method.
> >
> > [1] https://github.com/apache/maven-dependency-analyzer/pull/71
> > [2] https://www.slf4j.org/legacy.html
> >
> >
> > --
> > Sławomir Jaranowski
> >
>

Re: Logging in Maven Plugins - Bridging

2022-11-04 Thread Tamás Cservenák

Howdy,

Will we keep asking the same questions over and over again? Until we get
the "wanted" answer?

Maven core and ecosystem uses SLF4J API. Full stop.

Just use SLF4J API, and you will get a pre-configured back-end as well.
Done.

Now,. this story keeps popping up: "plugin developers using framework"
begs the question:
what framework are we talking about? And how common is this story? What
percentage of Maven
plugins USE a "framework"?

my 5 cents.
T

On Fri, Nov 4, 2022 at 11:56 AM Slawomir Jaranowski 
wrote:

> Hi,
>
> I want to start ( again :-) ) a discussion about logging in Maven plugins.
>
> First I agree that plugin developers should use logging methods provided by
> Plugin api.
>
> But we can not expect plugin developers to write everything from scratch.
> In many cases they may want to use an external library to do tasks needed
> by the plugin.
>
> We don't have any control over what logging framework is used in the
> external library used by plugin developers.
>
> We also maintain some libraries which can be used by plugin and also as
> standalone in another project.
> In such a case the question is - what logging we should use [1]?
>
> Last time I did a test, I use Java util logging from JDK in the Maven
> plugin.
> I see that Java util logging use default configuration, eg. we will have
> two lines for one log event.
> Even more options -q and -X have no effect for such a logger.
>
> One of the solution for such problem is using "Bridging" methods supported
> by slf4j [2]
> Probably all of existing and future logging frameworks can not be covered -
> but most of common using will be.
>
> I hope that, even if we will want to change the logging framework used
> internally in Maven, we can also use the same method.
>
> [1] https://github.com/apache/maven-dependency-analyzer/pull/71
> [2] https://www.slf4j.org/legacy.html
>
>
> --
> Sławomir Jaranowski
>

Re: Logging in Maven Plugins - Bridging