You are correct. And after looking at the class and at Liquibase master this code is now completely broken and should be dropped. 3.5.3 is the latest Liquibase release and the code possibly still works with that, although the unit tests certainly don’t prove that. But the code in master has been changed so that our code won’t compile. Liquibase in master is also hard-coded to use SLF4J.
I would suggest that whoever needs this should create a PR with Liquibase. I have no interest in keeping this component up to date. Note that removing this would definitely necessitate a 2.11.0 release. Ralph > On Jan 14, 2018, at 9:25 PM, Matt Sicker <[email protected]> wrote: > > From when I used log4j-liquibase in the past, it doesn't log _to_ > liquibase; instead, it offers an implementation of its internal logger > logic which doesn't use any existing facade by default. > > On 14 January 2018 at 17:14, Ralph Goers <[email protected]> wrote: > >> Ok. >> >> If we do this we should release that before we remove them from a Log4J >> release to minimize confusion. >> >> Sent from my iPhone >> >>> On Jan 14, 2018, at 3:47 PM, Remko Popma <[email protected]> wrote: >>> >>> No objection from me. >>> >>> Let’s make it a community goal to speed up the Log4j2 build. We should >> start by creating a JIRA epic (it’s in maintenance now but when it’s back >> up). >>> >>> (Shameless plug) Every java main() method deserves http://picocli.info >>> >>>> On Jan 15, 2018, at 6:11, Ralph Goers <[email protected]> >> wrote: >>>> >>>> I don’t believe the components listed in the subject line should be >> part of the main flume build and would like to see them moved to the >> logging-log4j-plugins project. The only problem is that the modules and >> maven coordinates need to change since the version numbers will be going >> backwards. I would propose we solve that by adding “plugin” to the jar >> names. >>>> >>>> Ralph >>> >> >> >> > > > -- > Matt Sicker <[email protected]>
