I think we should aim for all modules having only required dependencies. We should not add any new optional dependencies, and all new modules should only have required dependencies.
Maybe we won't be able to get rid of all optional dependencies in log4j-core right away, though. Maybe we will release 2.9 with a few optional dependencies left. On Tue, Apr 25, 2017 at 4:03 PM, 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. > > > -- [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.
