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