For what it’s worth, I’m happy to review Log4j Audit as many times as desired. :-)
For log4j-server (and future other components in separate repos): is it possible to set up a continuous build that compiles this component and runs the tests every time commits *to the main Log4j2 project* are pushed? That would help detect breaking changes, which is my key concern with moving stuff out to separate repos. This is not a precondition for the releases Ralph mentioned, but we should test this idea with log4j-server before proceeding with the modularization. (Shameless plug) Every java main() method deserves http://picocli.info > On Feb 13, 2018, at 6:46, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > My thoughts were to do it this past weekend but I spent the whole weekend > working on the documentation for Log4j Audit (please review). I plan to use > the next several days to review what is in 2.11 and what other bugs I see > that are very important that should be resolved there. I will also probably > do my usual pre-release vetting over the next few days. Given that I’d like > to get it done asap. > > That said, I’d also like to get a release of Log4j Audit as well as Log4j > Server. I expect Log4j Audit will take a bit longer to release though as I am > sure there are things that still need to be improved. Log4j Server might take > even longer as I don’t believe it has a site build at all. It probably > doesn’t need much of one though. > > Ralph > > > >> On Feb 12, 2018, at 2:08 PM, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> Hi All: >> >> Any thoughts on the timing for 2.11.0? >> >> Gary >> >>> On Mon, Jan 29, 2018 at 3:00 PM, Remko Popma <remko.po...@gmail.com> wrote: >>> >>> I will fix picocli before we get to that point. >>> >>> (Shameless plug) Every java main() method deserves http://picocli.info >>> >>>>> On Jan 30, 2018, at 4:07, Gary Gregory <garydgreg...@gmail.com> wrote: >>>>> >>>>> On Mon, Jan 29, 2018 at 11:07 AM, Remko Popma <remko.po...@gmail.com> >>> wrote: >>>>> >>>>> The log4j-api module could benefit from a util.internal package where we >>>>> move the util classes that are private and should not be exported. >>>>> Potentially an idea for a 3.0 release. >>>>> >>>>> (Shameless plug) Every java main() method deserves http://picocli.info >>>> >>>> >>>> Speaking of Picoli: It imports java.sql, which it should not for core to >>>> depend only on java.base. How should we deal with that? >>>> >>>> Gary >>>> >>>> >>>>> >>>>> >>>>>> On Jan 30, 2018, at 2:41, Remko Popma <remko.po...@gmail.com> wrote: >>>>>> >>>>>> If we want to do a 2.11 release that is binary compatible, I believe >>>>> that commit 21bc3aa is the last commit to include. >>>>>> From the following commit (ba658a0) we start to move classes and rename >>>>> packages - this would better fit in a 3.0 release where users would >>> expect >>>>> some breaking changes in core. >>>>>> >>>>>>> On Tue, Jan 30, 2018 at 2:37 AM, Matt Sicker <boa...@gmail.com> >>> wrote: >>>>>>> An SPI for log4j-core is one thing (also plugin factory cleanup). I'd >>>>> like >>>>>>> to see an improved plugin cache file that doesn't require a special >>>>> plugin >>>>>>> to merge them together when shading jars (would be better to just be >>>>> cat'd >>>>>>> together like a META-INF/services/ file). Removal of deprecated APIs >>>>> would >>>>>>> also be great. >>>>>>> >>>>>>> A 3.0 release also provides the ability to break APIs entirely if >>> there >>>>> are >>>>>>> any awkward design decisions we found while incorporating GC-free >>>>> logging >>>>>>> and other nifty performance improvements. Utilising Java 8, we also >>> have >>>>>>> the ability to support fully non-blocking asynchronous APIs using >>>>>>> CompleteableFuture which is rather interesting to me as well >>>>> (particularly >>>>>>> for networked appenders that provide async or reactive clients). >>>>>>> >>>>>>> As for bumping the version to 3.0 based on modules we already have, I >>>>>>> thought the main version was tied specifically to log4j-api. >>>>>>> >>>>>>> On 29 January 2018 at 11:28, Gary Gregory <garydgreg...@gmail.com> >>>>> wrote: >>>>>>> >>>>>>>> On Mon, Jan 29, 2018 at 10:27 AM, Gary Gregory < >>>>> garydgreg...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker <boa...@gmail.com> >>>>> wrote: >>>>>>>>> >>>>>>>>>> I'd be +1 for Java 8, but making a 3.0 release is a different >>>>> story. For >>>>>>>>>> that, I'd like to see a lot more than just the Java version >>>>> increase. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I think that a 3.0 would mark: >>>>>>>>> - A major change: Java 7 to Java 8 >>>>>>>>> - The internal clean up (in progress) with all the new modules >>>>>>>>> - Others stuff like maybe an SPI. >>>>>>>>> >>>>>>>> >>>>>>>> I would be happy to see an SPI for a 3.1.0 so we can take more time >>>>> with >>>>>>>> it. >>>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Pushed back to 4.0 would be: >>>>>>>>> - Remove deprecated classes and methods >>>>>>>>> - Other stuff? >>>>>>>>> >>>>>>>>> Gary >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 29 January 2018 at 11:07, Gary Gregory <garydgreg...@gmail.com> >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> +1 to Java 8 now and call the next release 3.0. >>>>>>>>>>> >>>>>>>>>>> Gary >>>>>>>>>>> >>>>>>>>>>> On Mon, Jan 29, 2018 at 10:03 AM, Ralph Goers < >>>>>>>>>> ralph.go...@dslextreme.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Ceki has started a poll to upgrade Logback to Java 8 - >>>>>>>>>>>> https://doodle.com/poll/s7n3wk59694pmnbs < >>>>> https://doodle.com/poll/ >>>>>>>>>>>> s7n3wk59694pmnbs>. The last poll I saw was in May of last >>>>> year that >>>>>>>>>> had >>>>>>>>>>>> Java 7 at about 30%. https://plumbr.io/blog/java/ >>>>>>>>>>>> java-version-and-vendor-data-analyzed-2017-edition < >>>>>>>>>>>> https://plumbr.io/blog/java/java-version-and-vendor-data- >>>>>>>>>>>> analyzed-2017-edition>. Based on the Java 6 graph I anticipate >>>>> that >>>>>>>>>> Java >>>>>>>>>>>> 7 will be under 20% this year. I had been thinking that >>>>> upgrading to >>>>>>>>>>> Java 8 >>>>>>>>>>>> in September or so would be the right time, but with all this >>>>>>>>>>>> modularization work I am wondering if moving to Java 8 now >>>>> makes >>>>>>>> more >>>>>>>>>>> sense. >>>>>>>>>>>> >>>>>>>>>>>> Thoughts? >>>>>>>>>>>> >>>>>>>>>>>> Ralph >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matt Sicker <boa...@gmail.com> >>>>>> >>>>> >>> > >
