We have to do something. I am about 3/4 of the way creating java9 modules and I am not happy with core at all. Far too many classes have to be exported as you can only name packages, not classes.
I think all the configuration stuff will need to stay in core, which means the optional dependency on Jackson will remain, but I could be convinced otherwise. Ralph > On Apr 23, 2017, at 10:45 AM, Matt Sicker <boa...@gmail.com> wrote: > > I think I brought this topic up like 3 years ago when I was working on > initial OSGi support, but now that we have 3 more years worth of code > additions and optional features, I think this might be a more appropriate > time to discuss it again in light of experience. > > Building log4j-core itself already takes a long time, and many plugins > aren't updated very often at all. In the past, requiring users to simply > add log4j-core plus any transitive dependencies to use optional features > seemed to work well enough, but I still think that's a confusing > distribution mechanism as demonstrated by the numerous bug reports and > Stack Overflow posts regarding missing transitive dependencies for various > features. I spent some time experimenting with Log4j Boot a little while > ago to help alleviate this problem, but this may be unnecessary if we can > agree to modularize log4j-core itself. > > I have two different proposals, both of which can be used at the same time. > > 1. Split out everything from log4j-core that requires 3rd party > dependencies (except for AsyncLogger, though perhaps we could consider > shading and renaming those classes like some other low level libraries do > with JCTools). Ideally, I'd like to see each module have required > dependencies instead of optional ones, so that if, for instance, I include > a "log4j-config-yaml" dependency, I know that Log4j will support YAML > configuration without having to specify the individual Jackson dependencies. > > 2. Split out from log4j-core a sort of log4j-spi module which defines > interfaces, abstract classes, and annotations for plugins that would be > promoted to the same level of backwards compatibility guarantees as > log4j-api. This would aid in cementing what we really wish to maintain > compatibility with in the backend while allowing other modules to have less > strict guarantees. > > With proposal #1, I'd think that we could more easily start moving modules > into separate repositories and release trains. Without #2, though, this > makes version support more annoying to handle, but that's what we'll face > regardless as we separate more repositories. If we go this route, then > there will be no need for a Log4j Boot subproject. > > What do you all think? > > -- > Matt Sicker <boa...@gmail.com>
