I don’t really care what doc format the manual uses, so long as they are all the same and it is easy to update the manual outside of a release.
Ralph > On May 18, 2022, at 4:15 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > 5. Manual is migrated from Markdown and XDOC to AsciiDoc – plus, 2 Markdown > files, sadly. > > On Tue, May 3, 2022 at 3:38 PM Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > >> Hi everyone, >> >> This topic has been discussed several times, but the list of features that >> need to be in version 3.0 is still fuzzy to me. From what I gathered >> version 3.0 requires: >> >> 1. JPMS support with non-automatic modules. This seems to be done for >> `log4j-api`, `log4j-plugins` and partially for `log4j-core`. The remaining >> modules need to be converted and I think there are still some classes if >> `log4j-api`, `log4j-plugins` and `log4j-core` that we can move to private >> packages. For example all the implementations of `PropertySource` in >> `log4j-api` do not need to be exported. >> >> 2. A DI system, which is certainly ready. However there are still places in >> the code where it is not used. For example the managers are still directly >> instantiated by the appenders, as well as some `log4j-1.2-api` builders >> that require constructor parameters. >> >> 3. The properties enhancement ( >> https://cwiki.apache.org/confluence/display/LOGGING/Properties+Enhancement >> ) >> proposed by Ralph. Personally I would like a `log4j-api` jar common to >> multiple web applications to be able to correctly detect a per-webapp >> `log4j2.configurationFile` property. >> >> 4. We could profit from the major version change to move some things >> around: for example do we really need three different file appenders? I >> think that from a use perspective a single `FileAppender` with three >> different file managers would be more intuitive. >> >> Piotr >>
