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 <elh...@ibiblio.org> 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 <garydgreg...@gmail.com> > wrote: > > > > On Sat, Nov 5, 2022, 09:09 Elliotte Rusty Harold <elh...@ibiblio.org> > 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 > > > <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 > > > > > > > > > > > > -- > > > 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 > > -- Sławomir Jaranowski
