Re: Logging in Maven Plugins - Bridging

[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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



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

[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

[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

[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

[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

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

Re: Logging in Maven Plugins - Bridging

[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

[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

[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

[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

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

Re: Logging in Maven Plugins - Bridging

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



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

Re: Logging in Maven Plugins - Bridging

[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, 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 ( a

Re: Logging in Maven Plugins - Bridging

[Romain Manni-Bucau]

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

Re: Logging in Maven Plugins - Bridging

[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

[Romain Manni-Bucau]

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

[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

[Romain Manni-Bucau]

Hi,

+1 for JUL, it is the most portable and less intrusive solution since it is
built-in, graalvm friendly (mvnd) and any backend compatible (slf4j,
logback directly, log4j2, ...).
It is always a pity for a solution which can embedded user code -
mojo/extensions - to force a logging library IMHO since it is never the
right one or the right version.

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



Le ven. 4 nov. 2022 à 12:12, Gary Gregory  a écrit :

> And let's not forget that Log4j also is a facade API:
> https://logging.apache.org/log4j/2.x/manual/api-separation.html
>
> Gary
>
>
> On Fri, Nov 4, 2022, 06:56 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

[Gary Gregory]

And let's not forget that Log4j also is a facade API:
https://logging.apache.org/log4j/2.x/manual/api-separation.html

Gary


On Fri, Nov 4, 2022, 06:56 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
>