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 <[email protected]>
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 <[email protected]> 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 <
> [email protected]>
> > 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 <[email protected]>
> 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, <[email protected]>
> > 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.
> > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to