The point of Log4j Boot was to aid in using the correct dependencies for various optional features. As we’ve split those optional features out from core into appropriate modules, that makes Log4j Boot moot as the individual modules will do what this repo was designed to do for 2.x.
I’d be alright with archiving the repo at this point. > On Sep 13, 2023, at 5:03 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > As far as I am concerned this is totally up to Matt. He created the repo. > >> On Sep 13, 2023, at 7:00 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> >> wrote: >> >> Hi Volkan, >> >> On Wed, 13 Sept 2023 at 15:34, Volkan Yazıcı <vol...@yazi.ci> wrote: >>> >>> `logging-log4j-boot` <https://github.com/apache/logging-log4j-boot>, last >>> touched 6 years ago, is a spin-off from LOG4J2-1775 >>> <https://issues.apache.org/jira/browse/LOG4J2-1775>, where it is stated >>> that *"The Log4j Boot concept can be superseded by the increased >>> modularization being done in 3.0. No longer relevant."* I want to archive >>> this repository. Objections? >> >> I see `log4j-boot` as a possibly light alternative to the logging part >> of Spring Boot. > > I don’t believe it was ever intended to be an alternative to Spring Boot. > Matt seemed to have an idea of using this to create various kinds of > QuickStarts for various types of applications. I never quite grasped how he > planned to do that. > >> >> While configuring a logging backend with most APIs requires just the >> right dependencies on the classpath, users might still need some >> programmatic help to configure JUL. >> >> IMHO Log4j Boot could do just that, i.e. check if Logback or Log4j >> Core are on the classpath and either: >> * set the appropriate `LogManager` property if it is not too late, >> * or configure a JUL handler to forward everything to the right API. >> > > Yes, Spring Boot does just that. But doing that in a generic way without any > other kind of framework seems impractical to me. But I would be willing to be > proved wrong. > > Ralph >
