Jackson is used to parse JSON configuration files and JMX is currently defaulted to be always enabled.
Ralph > On Apr 12, 2014, at 3:24 AM, Łukasz Dywicki <l...@code-house.org> wrote: > > Ralph, > For these who wants a "big” log4j you might provide aggregate JAR just like > astyanax does. I think it’s much easier going this direction than other way > around. Fine grained dependencies are proof of good library design. In slf4j > epoch developers do not depend on any log4j code except test scope where > mostly used is FileAppender. During deployment time it doesn’t make big > difference too because only one place which would be affected is assembly. I > can also imagine that some people could still love spring log4j stuff and > will not need direct log4j support for it. > > I can understand that disruptor might be mandatory to provide asynchronous > behaviour but why JMX and Jackson could not be separated? > > Best regards, > Łukasz Dywicki > -- > l...@code-house.org > Twitter: ldywicki > Blog: http://dywicki.pl > Code-House - http://code-house.org > >> Wiadomość napisana przez Ralph Goers <ralph.go...@dslextreme.com> w dniu 12 >> kwi 2014, o godz. 06:26: >> >> There is a balance that needs to be struck here. We don’t want to add >> support for OSGi at the cost of forcing non-OSGi users to have to include a >> bunch of Log4j dependencies. That said, I suggest the other day that we >> might want to split some things that a majority of our users will rarely use >> into other modules, possible in a companion project to the Log4j kernel. >> >> We actually have a few dependencies, such as Jackson, the disruptor, and JMX >> that are optional but really can’t be separated from the core. >> >> That said, an analysis of what could be separated is warranted. >> >> Ralph >> >>> On Apr 11, 2014, at 3:40 PM, Łukasz Dywicki <l...@code-house.org> wrote: >>> >>> Hey all, >>> Apachecon has been ended so I am following the promise I did - I’ve taken a >>> look on the log4j build to check what’s going on with OSGi stuff. Currently >>> OSGi bundles are split from main log4j-core which I think leads to >>> maintanance trouble also number of dependencies of log4j-core seems to be >>> very high. If we could split the log4j-core into smaller modules (mongodb, >>> jms, jmx, web) then there will be no need to keep log4j-osgi and it’s >>> submodules. >>> According to maven guides [1] "Optional dependencies are used when it's not >>> really possible (for whatever reason) to split a project up into >>> sub-modules”, I think it will also make library design much more clear and >>> will avoid making unecessary inner code deps. Seems that big, aggregate >>> modules, are always grow to size which require major work to split them to >>> make both: maintanance and community involvement possible. >>> >>> [1] >>> https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html >>> >>> Cheers, >>> Łukasz Dywicki >>> -- >>> l...@code-house.org >>> Twitter: ldywicki >>> Blog: http://dywicki.pl >>> Code-House - http://code-house.org >
