That would be the goal. Then we can have a log4j-core which has all the main plugins (file-related mostly) and other log4j addons for the 3rd party dependency ones.
On 24 April 2017 at 09:47, Mikael Ståldal <mikael.stal...@magine.com> wrote: > I guess this means that a plugin only needs to depend on log4j-spi (and > probably on log4j-api), not on log4j-core or anything else log4j-*. > > That would be good. > > On Mon, Apr 24, 2017 at 4:44 PM, Matt Sicker <boa...@gmail.com> wrote: > > > 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> > > > > > > -- > [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>
