You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Elliotte Rusty Harold <el...@ibiblio.org> on 2023/02/19 13:58:36 UTC
Halve the logging
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
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Halve the logging
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <rm...@gmail.com>
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 <ta...@cservenak.net> 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 <
> rmannibucau@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 <ta...@cservenak.net> 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 <
> > > rmannibucau@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 <
> bmarwell@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, <mi...@apache.org>
> > > > 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
> > > > > > > <value>, similar Tamás did with Resolver transports.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Halve the logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ta...@cservenak.net> 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 <rm...@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 <ta...@cservenak.net> 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 <
> > rmannibucau@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 <bmarwell@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, <mi...@apache.org>
> > > 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
> > > > > > <value>, similar Tamás did with Resolver transports.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Halve the logging
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <rm...@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 <ta...@cservenak.net> 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 <
> rmannibucau@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 <bm...@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, <mi...@apache.org>
> > 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
> > > > > <value>, similar Tamás did with Resolver transports.
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Halve the logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ta...@cservenak.net> 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 <rm...@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 <bm...@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, <mi...@apache.org>
> 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
> > > > <value>, similar Tamás did with Resolver transports.
> > > >
> > > >
> > >
> >
>
Re: Halve the logging
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <rm...@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 <bm...@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, <mi...@apache.org> 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
> > > <value>, similar Tamás did with Resolver transports.
> > >
> > >
> >
>
Re: Halve the logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <bm...@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, <mi...@apache.org> 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
> > <value>, similar Tamás did with Resolver transports.
> >
> >
>
Re: Halve the logging
Posted by Benjamin Marwell <bm...@apache.org>.
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, <mi...@apache.org> 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
> <value>, similar Tamás did with Resolver transports.
>
>
Re: Halve the logging
Posted by Michael Osipov <mi...@apache.org>.
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
<value>, similar Tamás did with Resolver transports.
Re: Halve the logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <el...@ibiblio.org> a
écrit :
> On Sun, Feb 19, 2023 at 2:02 PM Michael Osipov <mi...@apache.org>
> 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
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Halve the logging
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sun, Feb 19, 2023 at 2:02 PM Michael Osipov <mi...@apache.org> 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
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Halve the logging
Posted by Michael Osipov <mi...@apache.org>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Halve the logging
Posted by Gary Gregory <ga...@gmail.com>.
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 <ta...@cservenak.net> 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 <el...@ibiblio.org>
> 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
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Halve the logging
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <el...@ibiblio.org>
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
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>