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>
>>>>>> 
>>>>> 
>>> 
> 
> 

Reply via email to