log4j-spi is to make a well-defined API for plugins including a semantically versioned Appender, Filter, Layout, etc., interfaces and abstract classes, along with the annotations and whatnot. It'd be treated similarly to log4j-api in that regard.
On 25 April 2017 at 09:03, Gary Gregory <garydgreg...@gmail.com> wrote: > We should have consensus on the big picture here... are we all Ok with the > idea of all modules only having _required_ dependencies? > > Gary > > On Apr 25, 2017 6:57 AM, "Remko Popma" <remko.po...@gmail.com> wrote: > > > Nice analysis Mikael! > > > > I'm a bit fuzzy on log4j-spi, what was that for again? The list says > "core > > will depend on spi" but I think it's worth making an effort to ensure > that > > basic (file) logging behavior only needs core+API... Why does spi need to > > be separated from core? > > > > My first thought about jdbc was that since jdbc doesn't require external > > dependencies we should probably leave it in core. I guess it depends on > > what we're trying to achieve with (or how far we want to take) the > > modularization: do we want to reduce core to its absolute minimum or are > we > > aiming to split off external dependencies? > > > > Looking at the list I can see how many of these make sense and at the > same > > time I'm thinking, that's a lot of modules! :-) > > > > Remko > > > > > > (Shameless plug) Every main() method deserves http://picocli.info > > > > > On Apr 25, 2017, at 18:51, Mikael Ståldal <mikael.stal...@magine.com> > > wrote: > > > > > > I guess that log4-core will become: > > > > > > - log4j-core (will depend on log4j-spi) > > > - log4j-spi > > > - log4j-csv > > > - log4j-xml (XmlLayout) > > > - log4j-json (JsonLayout) > > > - log4j-yaml (YamlLayout) > > > - log4j-kafka > > > - log4j-smtp > > > - log4j-jms > > > - log4j-jdbc (or can this be kept in log4j-core?) > > > - log4j-jpa > > > - log4j-zeromq > > > - log4j-server (already done, not yet released) > > > - log4j-tools (command line tools) > > > > > > > > > Then we should also split log4j-nosql: > > > > > > - log4j-cassandra > > > - log4j-couchdb > > > - log4j-mongodb > > > - log4j-lucene (new, under development) > > > > > > > > > > > >> On Mon, Apr 24, 2017 at 7:43 PM, Remko Popma <remko.po...@gmail.com> > > wrote: > > >> > > >> How many new modules are we talking about, concretely? > > >> > > >> Matt mentioned the StackOverflow questions about transitive > dependencies > > >> etc, but I imagine splitting log4j-core into 5 or more new modules > will > > >> also cause confusion... It won't be trivial for users to figure out > > which > > >> of the many modules they do or don't need. The coarse granularity of > the > > >> current modules is a good thing for users. > > >> > > >> What problem are we trying to solve? And how can we solve it with the > > least > > >> disruption to our users? > > >> > > >> Would it be an idea, for example, to provide separate jars for the > > separate > > >> modules, but in addition create a combined jar (log4j-core-all) that > > >> contains all the classes in log4j-core as well as the classes in the > new > > >> modules we split out from core? > > >> > > >> > > >>> On Tue, Apr 25, 2017 at 2:00 AM, Matt Sicker <boa...@gmail.com> > wrote: > > >>> > > >>> I agree with Ralph here. I'm sure we'll figure out rather quickly > which > > >>> modules are easy to put into rarely updated repositories. > > >>> > > >>> On 24 April 2017 at 11:39, Ralph Goers <ralph.go...@dslextreme.com> > > >> wrote: > > >>> > > >>>> I would prefer a hybrid approach. First things should be moved to > > >>>> separate modules. Then, if they don’t seem to be modified frequently > > >> they > > >>>> can be moved to a separate repo. For example, I think it would be OK > > >> for > > >>>> the Flume Appender to be in a separate repo. It hasn’t changed in > > >> quite a > > >>>> while and I can’t remember the last time it was modified due to > > changes > > >>> in > > >>>> Log4j it has and while continue to change with changes made in Flume > > >>>> releases. I imagine we have quite a few components that are > similar. > > >>>> > > >>>> Ralph > > >>>> > > >>>>> On Apr 24, 2017, at 8:39 AM, Gary Gregory <garydgreg...@gmail.com> > > >>>> wrote: > > >>>>> > > >>>>> On Apr 24, 2017 2:38 AM, "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. > > >>>>> > > >>>>> > > >>>>> I do not like more repos either. Since we have already gone down > the > > >>> more > > >>>>> modules road, I say we keep going. > > >>>>> > > >>>>> Gary > > >>>>> > > >>>>> > > >>>>> 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>