I also agree that modules should really stick to required dependencies.

As for only requiring log4j-core, the idea here is that you could still
just do:

compile 'org.apache.logging.log4j:log4j-core:2.+'

or whatever the equivalent is for your build system, and you'll still get
log4j-api and anything else required. You'd only need log4j-api for
logging, log4j-spi for writing custom plugins, or log4j-core to get the
standard plugins.

On 25 April 2017 at 09:07, Mikael Ståldal <mikael.stal...@magine.com> wrote:

> 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.
>



-- 
Matt Sicker <boa...@gmail.com>

Reply via email to