Setting up jobs like that in Jenkins is pretty easy to do. Ralph
> On Feb 12, 2018, at 4:06 PM, Remko Popma <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> wrote: >>> >>> Hi All: >>> >>> Any thoughts on the timing for 2.11.0? >>> >>> Gary >>> >>>> On Mon, Jan 29, 2018 at 3:00 PM, Remko Popma <[email protected]> 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 <[email protected]> wrote: >>>>>> >>>>>> On Mon, Jan 29, 2018 at 11:07 AM, Remko Popma <[email protected]> >>>> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>>>> wrote: >>>>>>>> >>>>>>>>> On Mon, Jan 29, 2018 at 10:27 AM, Gary Gregory < >>>>>> [email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker <[email protected]> >>>>>> 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 <[email protected]> >>>>>>>>> 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 < >>>>>>>>>>> [email protected]> >>>>>>>>>>>> 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 <[email protected]> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matt Sicker <[email protected]> >>>>>>> >>>>>> >>>> >> >> >
