Keeping configuration/plugin processing code inside log4j-spi should probably be marked clearly which classes are public APIs and which aren't then. I'm not sure how many classes would need to be moved around, but that will require some experimentation to figure out anyways.
On 24 April 2017 at 04:38, Mikael Ståldal <mikael.stal...@magine.com> wrote: > I fully agree with Matt's both proposals. > > I'm skeptic to creating more repositories (than we already have) though. I > think that we should start by splitting out modules from log4j-core and > keep those modules in the main repository with synchronized versioning and > releases, at least for the 2.9 release. We can always move those modules to > other repositories later if we want to. > > It is a lot of administrative work to create a new repository (as we have > seen for log4j-scala), I don't want us to do all that work over and over > again unless really necessary. > > We have a JIRA ticket for this: > https://issues.apache.org/jira/browse/LOG4J2-1650 > > I have already started by breaking out log4j-server: > https://issues.apache.org/jira/browse/LOG4J2-1851 > > I think the next step is to break out plugins (layouts and appenders) with > optional 3rd party dependencies into their own modules. > > > On Sun, Apr 23, 2017 at 7:45 PM, 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> > > > > > > -- > [image: MagineTV] > > *Mikael Ståldal* > Senior software developer > > *Magine TV* > mikael.stal...@magine.com > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com > > Privileged and/or Confidential Information may be contained in this > message. If you are not the addressee indicated in this message > (or responsible for delivery of the message to such a person), you may not > copy or deliver this message to anyone. In such case, > you should destroy this message and kindly notify the sender by reply > email. > -- Matt Sicker <boa...@gmail.com>
