On Sat, Apr 12, 2014 at 10:20 AM, Ralph Goers <rgo...@apache.org> wrote:
> Jackson is used to parse JSON configuration files and JMX is currently > defaulted to be always enabled. > Wait, some one is going to want to split each configuration format processing into it's own module to reduce dependencies.. ;) G > > 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 > > > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
