Setting up jobs like that in Jenkins is pretty easy to do.

Ralph

> On Feb 12, 2018, at 4:06 PM, Remko Popma <remko.po...@gmail.com> 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 <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