You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Volkan Yazıcı <vo...@gmail.com> on 2021/06/03 13:21:27 UTC
Re: [apache/logging-log4j2] Liquibase 4.x Compatibility (#503)
I am just curious, why is the Liquibase logger a part of the Log4j project?
Shouldn't Liquibase itself be providing the logging bridges of their
software for certain logging backends?
On Wed, Jun 2, 2021 at 10:17 PM Nathan Voxland <no...@github.com>
wrote:
> Overview
>
> Liquibase 3.6 as well as 4.0 introduced API compatibility issues with the
> current log4j-liquibase codebase. See liquibase/liquibase#1777
> <https://github.com/liquibase/liquibase/issues/1777>
>
> This updates the code to be compatible with 4.0+ while still supporting
> 3.5 and 3.6+ users.
> ------------------------------
> You can view, comment on, or merge this pull request online at:
>
> https://github.com/apache/logging-log4j2/pull/503
> Commit Summary
>
> - Updated log4j-liquibase to be compatible with both 3.x and 4.x
> versions of Liquibase
> - Updated log4j-liquibase to be compatible with both 3.x and 4.x
> versions of Liquibase
>
> File Changes
>
> - *A*
> log4j-liquibase/src/main/java/liquibase/ext/logging/log4j2/DeprecatedLog4j2Logger.java
> <https://github.com/apache/logging-log4j2/pull/503/files#diff-aabadf00cbeee77ba36f78292fe7dc11fe16c3b46f2a8b64b93c219514fec86b>
> (189)
> - *M*
> log4j-liquibase/src/main/java/liquibase/ext/logging/log4j2/Log4j2Logger.java
> <https://github.com/apache/logging-log4j2/pull/503/files#diff-a3fb75cc20998f82ba5cb4783d5f57420eead2d5277b6007b8f23554fd25c714>
> (157)
> - *A*
> log4j-liquibase/src/main/java/liquibase/ext/logging/log4j2/Log4j2LoggerService.java
> <https://github.com/apache/logging-log4j2/pull/503/files#diff-62b7869399bb7251582033dd21d08acc257f56e3cd6bd426bc68e92f67e0ab11>
> (47)
> - *A*
> log4j-liquibase/src/main/resources/META-INF/services/liquibase.logging.LogService
> <https://github.com/apache/logging-log4j2/pull/503/files#diff-41f6a06104e2662ac0882a53045eb884cd5b9009d1e5de8e847e04b2aa79ac2b>
> (1)
> - *R*
> log4j-liquibase/src/test/java/liquibase/ext/logging/log4j2/DeprecatedLog4J2LoggerTest.java
> <https://github.com/apache/logging-log4j2/pull/503/files#diff-7b353543266b0e9219b856fac1c3df928764f8a41612e5e59ea3841b75e11d3e>
> (8)
> - *A*
> log4j-liquibase/src/test/java/liquibase/ext/logging/log4j2/Log4j2LoggerTest.java
> <https://github.com/apache/logging-log4j2/pull/503/files#diff-ae83836593517181c94282dfacab38f16e1741fa3503c1c4a5297753efe4e09d>
> (86)
> - *M* pom.xml
> <https://github.com/apache/logging-log4j2/pull/503/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8>
> (3)
>
> Patch Links:
>
> - https://github.com/apache/logging-log4j2/pull/503.patch
> - https://github.com/apache/logging-log4j2/pull/503.diff
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/logging-log4j2/pull/503>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAARTSNWLZC4VTOBYVGT4TTTQ2GT3ANCNFSM457M3ARA>
> .
>
Re: Breaking up modules into separate sub-projects
Posted by Gary Gregory <ga...@gmail.com>.
FWIW, my experience with GitHub actions over at Apache Commons is extremely
positive.
Gary
On Fri, Jun 11, 2021, 15:21 Matt Sicker <bo...@gmail.com> wrote:
> We can certainly set up CI to build on upstream snapshot releases or even
> nightly jobs.
>
> For improving the build time of core, that will require parallelizing tests
> like in api.
>
> On Fri, Jun 11, 2021 at 13:48 Volkan Yazıcı <vo...@gmail.com>
> wrote:
>
> > I agree with all the points (both pros and cons) you have shared.
> >
> > A small "core" will speed up the development and release cycle
> > significantly. Most of the time I skip a full Maven "verify", which is
> > taking more than half an hour on my machine.
> >
> > Regarding CI, I believe there will be a huge win too due to faster
> feedback
> > cycles. Also note that it is possible to trigger GitHub Actions workflows
> > from another repository change. Hence the consistency check across
> > repositories you have described can easily be set up.
> >
> > On Fri, Jun 11, 2021 at 7:45 PM Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> > > Not sure what you want a recap on. I see a few issues on both sides of
> > the
> > > coin:
> > >
> > > For splitting:
> > > 1. Many of the current modules rarely get modified. Creating a new
> > version
> > > of
> > > them with each release just so the release number matches seems silly.
> > > 2. Yes, creating a release is time consuming. When I am nearing the
> time
> > to
> > > perform a release I:
> > > a. Review PRs and Jira issues looking for ones that are either
> > critical,
> > > serious
> > > or easy to fix and try to address them. This typically involves
> > > running the
> > > build several times.
> > > b. Perform all the required release updates.
> > > c. Build the web site locally and inspect it.
> > > d. Follow the guide to actually perform the release.
> > > The prep time in step a is typically what takes the most time due to
> how
> > > many
> > > times I run the full build. This is where the most time savings would
> be
> > > since
> > > most of the changes occur in log4j-api and log4j-core, although the
> most
> > > time
> > > consuming part of the build is the log4j-core unit tests.
> > > 3. This might encourage everyone to run a full build for every commit.
> > >
> > > Against splitting:
> > > 1. Confusion over where a particular component can be found.
> > > 2. Although unlikely, it is possible a change in log4j-api or
> log4j-core
> > > could
> > > break something in one of the other modules and we wouldn’t find out
> > > immediately as we do today. This could be solved by setting up good
> > > Jenkins
> > > pipelines that cause all the sub projects to rebuild whenever the main
> > > module is built.
> > >
> > > Ralph
> > >
> > > > On Jun 11, 2021, at 10:12 AM, Gary Gregory <ga...@gmail.com>
> > > wrote:
> > > >
> > > > I am on 100% board with spliting up modules/artifacts to reduce the
> > "suck
> > > > the world in" issue. Splitting into separate repos/projects I have
> zero
> > > > interest in, I only see drawbacks. Version confusion, BOM POM or not,
> > > weird
> > > > dependeny issues, more fiddling with IDEs to make sure you can get
> > stuff
> > > > done, bleh.
> > > >
> > > > I know Ralph has been quite generous with him time in release
> > management
> > > > and has mentioned numerous time that he feels the current repository
> > size
> > > > leads to long release candiate build times. But I see this as a
> drive
> > to
> > > > break up the repository wrong headed. When I run any of the various
> > Maven
> > > > builds I use, some builds rebuilds various pieces needlessly,
> compiling
> > > > code when no recompilation is needed for example, running tests more
> > than
> > > > needed, and other Maven oddities. If the tooling is a problem, then
> > lets
> > > > look at that first.
> > > >
> > > > Maybe we could get a recap from Ralph?
> > > >
> > > > Gary
> > > >
> > > >
> > > > On Fri, Jun 11, 2021, 10:42 Volkan Yazıcı <vo...@gmail.com>
> > > wrote:
> > > >
> > > >> Gary, I thought you were on board with breaking up into separate
> > > projects.
> > > >> What do you propose instead?
> > > >>
> > > >> On Fri, Jun 11, 2021 at 12:22 PM Gary Gregory <
> garydgregory@gmail.com
> > >
> > > >> wrote:
> > > >>
> > > >>> From my POV, this will create an incomprehensible mess of versions
> > for
> > > >>> users. Big bummer.
> > > >>>
> > > >>> Gary
> > > >>>
> > > >>> On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <volkan.yazici@gmail.com
> >
> > > >> wrote:
> > > >>>
> > > >>>> To start the discussion for breaking up the modules into separate
> > > >>> projects,
> > > >>>> I propose the following structure:
> > > >>>>
> > > >>>> *logging-log4j*
> > > >>>> log4j-1.2-api
> > > >>>> log4j-api
> > > >>>> log4j-bom
> > > >>>> log4j-core
> > > >>>> log4j-core-its
> > > >>>> log4j-gctests
> > > >>>> log4j-iostreams
> > > >>>> log4j-layout-template-json
> > > >>>> log4j-perf
> > > >>>> log4j-plugins
> > > >>>>
> > > >>>> *logging-log4j-appender*
> > > >>>> log4j-cassandra
> > > >>>> log4j-couchdb
> > > >>>> log4j-csv
> > > >>>> log4j-flume-ng
> > > >>>> log4j-mongodb3
> > > >>>> log4j-mongodb4
> > > >>>> log4j-smtp
> > > >>>>
> > > >>>> *logging-log4j-appender-jdbc*
> > > >>>> log4j-jdbc (?)
> > > >>>> log4j-jdbc-dbcp2 (?)
> > > >>>> log4j-jpa
> > > >>>>
> > > >>>> *logging-log4j-appender-queue*
> > > >>>> log4j-jeromq
> > > >>>> log4j-jms
> > > >>>> log4j-kafka
> > > >>>> log4j-redis
> > > >>>>
> > > >>>> *logging-log4j-binding*
> > > >>>> log4j-jcl
> > > >>>> log4j-jpl
> > > >>>> log4j-jul
> > > >>>> log4j-liquibase
> > > >>>> log4j-slf4j18-impl
> > > >>>> log4j-slf4j-impl
> > > >>>> log4j-to-slf4j
> > > >>>>
> > > >>>> *logging-log4j-container*
> > > >>>> log4j-docker
> > > >>>> log4j-kubernetes
> > > >>>>
> > > >>>> *logging-log4j-gui*
> > > >>>> log4j-jmx-gui
> > > >>>>
> > > >>>> *logging-log4j-jee*
> > > >>>> log4j-appserver
> > > >>>> log4j-taglib
> > > >>>> log4j-web
> > > >>>>
> > > >>>> *logging-log4j-layout-jackson*
> > > >>>> log4j-layout-jackson
> > > >>>> log4j-layout-jackson-json
> > > >>>> log4j-layout-jackson-xml
> > > >>>> log4j-layout-jackson-yaml
> > > >>>>
> > > >>>> *logging-log4j-osgi*
> > > >>>> log4j-osgi
> > > >>>>
> > > >>>> *logging-log4j-spring*
> > > >>>> log4j-spring-boot
> > > >>>> log4j-spring-cloud-config
> > > >>>>
> > > >>>> Note that above breakdown contains every available module in
> master,
> > > >>> except
> > > >>>> log4j-samples, which has the following sub-modules:
> > > >>>>
> > > >>>> log4j-samples-loggerProperties (contains 2 very trivial example
> > > >> classes,
> > > >>>> log4j-core [tests] contains more comprehensive alternatives)
> > > >>>> log4j-samples-flume-remote (flume-specific)
> > > >>>> log4j-samples-flume-embedded (flume-specific)
> > > >>>> log4j-samples-flume-common (flume-specific)
> > > >>>> log4j-samples-configuration (contains 3 very trivial example
> > classes,
> > > >>>> log4j-core [tests] contains more comprehensive alternatives)
> > > >>>>
> > > >>>> I propose removing log4j-samples module and, if necessary, moving
> > > >>>> Flume-related parts to the log4j-flume-ng.
> > > >>>>
> > > >>>> I have kept log4j-layout-template-json in the logging-log4j
> project,
> > > >>> since
> > > >>>> it has no external dependencies. This said, I am okay with moving
> it
> > > >> to a
> > > >>>> separate logging-log4j-layout project.
> > > >>>>
> > > >>>> Please share your remarks. Eventually, I want to translate this
> > into a
> > > >>> JIRA
> > > >>>> ticket.
> > > >>>>
> > > >>>> Kind regards.
> > > >>>>
> > > >>>> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <
> > > >> ralph.goers@dslextreme.com>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> Gary,
> > > >>>>>
> > > >>>>> I am -1 to almost every item on your list.
> > > >>>>>
> > > >>>>> When I said break up I meant mostly moving most everything
> outside
> > of
> > > >>>>> log4j-core,
> > > >>>>> log4j-api, and log4j-plugins into separate repos such as
> > > >>>>> logging-log4j-nosql,
> > > >>>>> logging-log4j-pubsub, etc. These would not require groupId or
> > > >>> artifactId
> > > >>>>> changes
> > > >>>>> although the versioning would potentially be out of synch with
> the
> > > >> main
> > > >>>>> releases
> > > >>>>> as each would be on its own release cycle. This would greatly
> > > >> simplify
> > > >>>>> releasing
> > > >>>>> core but it would require careful though on what the versions
> would
> > > >> be
> > > >>>> for
> > > >>>>> the
> > > >>>>> “extra” projects.
> > > >>>>>
> > > >>>>> As for further breaking up core, that should revolve primarily
> > around
> > > >>>>> reducing the
> > > >>>>> dependencies listed in module-info.java to the bare minimum.
> > > >>>>>
> > > >>>>> There will be no log4j3. We cannot change groupIds, artifactIds,
> or
> > > >>>>> package names,
> > > >>>>> other than what has been done to support JPMS. A world in which a
> > > >>> log4j2
> > > >>>>> and
> > > >>>>> log4j3 try to co-exist would be an unmitigated disaster. Commons
> > can
> > > >>>>> happily get
> > > >>>>> away with that. Log4j cannot.
> > > >>>>>
> > > >>>>> If an application had both log4j2 and log4j3 jars present they
> > would
> > > >>> end
> > > >>>>> up with
> > > >>>>> multiple LoggerContexts, multiple Configurations, and multiple
> > > >> Appender
> > > >>>>> Managers
> > > >>>>> where today there is only a single one. That would mean two
> > instances
> > > >>> of
> > > >>>>> the same
> > > >>>>> configuration file would be active at once. So when it is time to
> > > >>>> rollover
> > > >>>>> it would
> > > >>>>> be performed twice instead of once as a simple example. For this
> > > >> reason
> > > >>>> we
> > > >>>>> CANNOT break backward compatibility.
> > > >>>>>
> > > >>>>> However, we are talking about runtime backward compatibility. The
> > > >>> Plugin
> > > >>>>> system
> > > >>>>> was changed internally in 3.0 so that plugins compiled with 3.0
> use
> > > >>>>> ServiceLoader
> > > >>>>> instead of the data file. However, it will still find and use 2.x
> > > >>> plugins
> > > >>>>> when they are
> > > >>>>> present and can be located.
> > > >>>>>
> > > >>>>> The meaning of this should be clear. It is 3.0 because to take
> > > >>> advantage
> > > >>>>> of its
> > > >>>>> features you may have to make code changes. But it will tolerate
> > code
> > > >>>> that
> > > >>>>> was
> > > >>>>> compiled for 2.x.
> > > >>>>>
> > > >>>>> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
> > > >>>>> 1. Plugins must be compiled with 3.0 to use the ServiceLoader
> > > >>> packaging.
> > > >>>>> 2. It requires Java 11. We still need to support Java 8.
> > > >>>>> 3. It fully supports JPMS. Release 2.x does not. It is likely
> that
> > > >>>>> applications with
> > > >>>>> multiple Module Layers might not be able to find all the plugins.
> > > >>> Adding
> > > >>>>> full JPMS
> > > >>>>> support to 2.x simply isn’t possible.
> > > >>>>> 4. It will be introducing new DI injection features not present
> in
> > > >> 2.x.
> > > >>>>>
> > > >>>>> Major releases do not imply that you are completely breaking
> > backward
> > > >>>>> compatibility.
> > > >>>>> They imply that some kind of compatibility is broken, which we
> are
> > > >>> doing
> > > >>>>> by
> > > >>>>> requiring coding changes to Plugins to compile with 3.0. This
> means
> > > >> we
> > > >>>>> need to
> > > >>>>> leave in any classes or methods that existing plugins might have
> > > >> used.
> > > >>> It
> > > >>>>> means
> > > >>>>> we have to continue using our own Supplier unless it can be
> > verified
> > > >>> that
> > > >>>>> an
> > > >>>>> application using the Supplier in 2.x can run with 3.0 even if it
> > is
> > > >>>>> converted to
> > > >>>>> java.util.function.Supplier. I have no idea if the code the
> > compiler
> > > >>>>> generates
> > > >>>>> for lambdas actually implements the declared interface or not.
> > > >>>>>
> > > >>>>> Log4j 3.0 is a major change. But that doesn’t mean we can screw
> our
> > > >>> users
> > > >>>>> by
> > > >>>>> breaking everything.
> > > >>>>>
> > > >>>>> Ralph
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>> On Jun 10, 2021, at 6:32 AM, Gary Gregory <
> garydgregory@gmail.com
> > >
> > > >>>>> wrote:
> > > >>>>>>
> > > >>>>>> These are all IMOs of course, YMMV:
> > > >>>>>> - What's the rush to 3.0?
> > > >>>>>>
> > > >>>>>> - I'm all for breaking up the core and other artifacts into more
> > > >>>>>> artifacts based on their dependencies requirement such that
> > > >> depending
> > > >>>>>> on Log4j 3 does not "suck in the world", for example, I should
> be
> > > >>> able
> > > >>>>>> to depend on a currently non-existent "log4j3-console" and only
> > > >> bring
> > > >>>>>> in a tiny bit of code (API, a tiny core, and no plugin system).
> I
> > > >> did
> > > >>>>>> a fair amount of breaking up of various artifacts a while back.
> > > >>>>>>
> > > >>>>>> - 3.0 is a MAJOR release that gives us the opportunity to drop
> > > >>>>>> deprecated APIs and code like our custom functional interfaces:
> > > >>>>>> Supplier and so on. If we do not clean up, then there is no
> point
> > > >> in
> > > >>> a
> > > >>>>>> major release. Basically, I expect to break binary and source
> > > >>>>>> compatibility.
> > > >>>>>>
> > > >>>>>> - 3.0 must be in a new package namespace and new Maven
> > > >> coordinates. I
> > > >>>>>> MUST be able to run Log4j 1, 2, and 3 in the same class loader.
> I
> > > >> can
> > > >>>>>> already run Log4j 1 and 2 side by side which is good.
> > > >>>>>>
> > > >>>>>> Gary
> > > >>>>>>
> > > >>>>>> On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
> > > >>> volkan.yazici@gmail.com
> > > >>>>>
> > > >>>>> wrote:
> > > >>>>>>>
> > > >>>>>>> Ralph, count me in for such a change. I really want to have
> > > >> separate
> > > >>>>>>> sub-projects for such modules. This will extremely speed up
> > > >>>>> build/release
> > > >>>>>>> times too, which is nowadays of uttermost importance to my
> peace
> > > >> of
> > > >>>> mind
> > > >>>>>>> while developing.
> > > >>>>>>>
> > > >>>>>>> This said, I am reluctant about such a major change when we are
> > > >> this
> > > >>>>> close
> > > >>>>>>> to the 3.0.0 release. I guess this would definitely postpone
> the
> > > >>> 3.0.0
> > > >>>>>>> release to 2022. This will probably break the backward
> > > >> compatibility
> > > >>>> at
> > > >>>>>>> least for the artifact groupId, am I wrong? Not to mention that
> > > >> the
> > > >>>>> entire
> > > >>>>>>> website needs to be adapted to this multi-project setup too. Is
> > > >>> there
> > > >>>>>>> anything else?
> > > >>>>>>>
> > > >>>>>>> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
> > > >>>> ralph.goers@dslextreme.com>
> > > >>>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> Yeah - I have proposed moving all these extra integrations to
> a
> > > >>>>> separate
> > > >>>>>>>> repo but
> > > >>>>>>>> I’ve never gotten consensus. I’d prefer to have a project like
> > > >>>>>>>> log4j-pubsub where
> > > >>>>>>>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all
> > the
> > > >>>> nosql
> > > >>>>>>>> modules, etc.
> > > >>>>>>>> The problem seems to be that some people believe that we would
> > > >> have
> > > >>>> to
> > > >>>>> cut
> > > >>>>>>>> a
> > > >>>>>>>> release of those every time we do a log4j release.
> > > >>>>>>>>
> > > >>>>>>>> If we were to do that 3.0 would be the right time.
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> > >
> >
>
Re: Breaking up modules into separate sub-projects
Posted by Matt Sicker <bo...@gmail.com>.
We can certainly set up CI to build on upstream snapshot releases or even
nightly jobs.
For improving the build time of core, that will require parallelizing tests
like in api.
On Fri, Jun 11, 2021 at 13:48 Volkan Yazıcı <vo...@gmail.com> wrote:
> I agree with all the points (both pros and cons) you have shared.
>
> A small "core" will speed up the development and release cycle
> significantly. Most of the time I skip a full Maven "verify", which is
> taking more than half an hour on my machine.
>
> Regarding CI, I believe there will be a huge win too due to faster feedback
> cycles. Also note that it is possible to trigger GitHub Actions workflows
> from another repository change. Hence the consistency check across
> repositories you have described can easily be set up.
>
> On Fri, Jun 11, 2021 at 7:45 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> > Not sure what you want a recap on. I see a few issues on both sides of
> the
> > coin:
> >
> > For splitting:
> > 1. Many of the current modules rarely get modified. Creating a new
> version
> > of
> > them with each release just so the release number matches seems silly.
> > 2. Yes, creating a release is time consuming. When I am nearing the time
> to
> > perform a release I:
> > a. Review PRs and Jira issues looking for ones that are either
> critical,
> > serious
> > or easy to fix and try to address them. This typically involves
> > running the
> > build several times.
> > b. Perform all the required release updates.
> > c. Build the web site locally and inspect it.
> > d. Follow the guide to actually perform the release.
> > The prep time in step a is typically what takes the most time due to how
> > many
> > times I run the full build. This is where the most time savings would be
> > since
> > most of the changes occur in log4j-api and log4j-core, although the most
> > time
> > consuming part of the build is the log4j-core unit tests.
> > 3. This might encourage everyone to run a full build for every commit.
> >
> > Against splitting:
> > 1. Confusion over where a particular component can be found.
> > 2. Although unlikely, it is possible a change in log4j-api or log4j-core
> > could
> > break something in one of the other modules and we wouldn’t find out
> > immediately as we do today. This could be solved by setting up good
> > Jenkins
> > pipelines that cause all the sub projects to rebuild whenever the main
> > module is built.
> >
> > Ralph
> >
> > > On Jun 11, 2021, at 10:12 AM, Gary Gregory <ga...@gmail.com>
> > wrote:
> > >
> > > I am on 100% board with spliting up modules/artifacts to reduce the
> "suck
> > > the world in" issue. Splitting into separate repos/projects I have zero
> > > interest in, I only see drawbacks. Version confusion, BOM POM or not,
> > weird
> > > dependeny issues, more fiddling with IDEs to make sure you can get
> stuff
> > > done, bleh.
> > >
> > > I know Ralph has been quite generous with him time in release
> management
> > > and has mentioned numerous time that he feels the current repository
> size
> > > leads to long release candiate build times. But I see this as a drive
> to
> > > break up the repository wrong headed. When I run any of the various
> Maven
> > > builds I use, some builds rebuilds various pieces needlessly, compiling
> > > code when no recompilation is needed for example, running tests more
> than
> > > needed, and other Maven oddities. If the tooling is a problem, then
> lets
> > > look at that first.
> > >
> > > Maybe we could get a recap from Ralph?
> > >
> > > Gary
> > >
> > >
> > > On Fri, Jun 11, 2021, 10:42 Volkan Yazıcı <vo...@gmail.com>
> > wrote:
> > >
> > >> Gary, I thought you were on board with breaking up into separate
> > projects.
> > >> What do you propose instead?
> > >>
> > >> On Fri, Jun 11, 2021 at 12:22 PM Gary Gregory <garydgregory@gmail.com
> >
> > >> wrote:
> > >>
> > >>> From my POV, this will create an incomprehensible mess of versions
> for
> > >>> users. Big bummer.
> > >>>
> > >>> Gary
> > >>>
> > >>> On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <vo...@gmail.com>
> > >> wrote:
> > >>>
> > >>>> To start the discussion for breaking up the modules into separate
> > >>> projects,
> > >>>> I propose the following structure:
> > >>>>
> > >>>> *logging-log4j*
> > >>>> log4j-1.2-api
> > >>>> log4j-api
> > >>>> log4j-bom
> > >>>> log4j-core
> > >>>> log4j-core-its
> > >>>> log4j-gctests
> > >>>> log4j-iostreams
> > >>>> log4j-layout-template-json
> > >>>> log4j-perf
> > >>>> log4j-plugins
> > >>>>
> > >>>> *logging-log4j-appender*
> > >>>> log4j-cassandra
> > >>>> log4j-couchdb
> > >>>> log4j-csv
> > >>>> log4j-flume-ng
> > >>>> log4j-mongodb3
> > >>>> log4j-mongodb4
> > >>>> log4j-smtp
> > >>>>
> > >>>> *logging-log4j-appender-jdbc*
> > >>>> log4j-jdbc (?)
> > >>>> log4j-jdbc-dbcp2 (?)
> > >>>> log4j-jpa
> > >>>>
> > >>>> *logging-log4j-appender-queue*
> > >>>> log4j-jeromq
> > >>>> log4j-jms
> > >>>> log4j-kafka
> > >>>> log4j-redis
> > >>>>
> > >>>> *logging-log4j-binding*
> > >>>> log4j-jcl
> > >>>> log4j-jpl
> > >>>> log4j-jul
> > >>>> log4j-liquibase
> > >>>> log4j-slf4j18-impl
> > >>>> log4j-slf4j-impl
> > >>>> log4j-to-slf4j
> > >>>>
> > >>>> *logging-log4j-container*
> > >>>> log4j-docker
> > >>>> log4j-kubernetes
> > >>>>
> > >>>> *logging-log4j-gui*
> > >>>> log4j-jmx-gui
> > >>>>
> > >>>> *logging-log4j-jee*
> > >>>> log4j-appserver
> > >>>> log4j-taglib
> > >>>> log4j-web
> > >>>>
> > >>>> *logging-log4j-layout-jackson*
> > >>>> log4j-layout-jackson
> > >>>> log4j-layout-jackson-json
> > >>>> log4j-layout-jackson-xml
> > >>>> log4j-layout-jackson-yaml
> > >>>>
> > >>>> *logging-log4j-osgi*
> > >>>> log4j-osgi
> > >>>>
> > >>>> *logging-log4j-spring*
> > >>>> log4j-spring-boot
> > >>>> log4j-spring-cloud-config
> > >>>>
> > >>>> Note that above breakdown contains every available module in master,
> > >>> except
> > >>>> log4j-samples, which has the following sub-modules:
> > >>>>
> > >>>> log4j-samples-loggerProperties (contains 2 very trivial example
> > >> classes,
> > >>>> log4j-core [tests] contains more comprehensive alternatives)
> > >>>> log4j-samples-flume-remote (flume-specific)
> > >>>> log4j-samples-flume-embedded (flume-specific)
> > >>>> log4j-samples-flume-common (flume-specific)
> > >>>> log4j-samples-configuration (contains 3 very trivial example
> classes,
> > >>>> log4j-core [tests] contains more comprehensive alternatives)
> > >>>>
> > >>>> I propose removing log4j-samples module and, if necessary, moving
> > >>>> Flume-related parts to the log4j-flume-ng.
> > >>>>
> > >>>> I have kept log4j-layout-template-json in the logging-log4j project,
> > >>> since
> > >>>> it has no external dependencies. This said, I am okay with moving it
> > >> to a
> > >>>> separate logging-log4j-layout project.
> > >>>>
> > >>>> Please share your remarks. Eventually, I want to translate this
> into a
> > >>> JIRA
> > >>>> ticket.
> > >>>>
> > >>>> Kind regards.
> > >>>>
> > >>>> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <
> > >> ralph.goers@dslextreme.com>
> > >>>> wrote:
> > >>>>
> > >>>>> Gary,
> > >>>>>
> > >>>>> I am -1 to almost every item on your list.
> > >>>>>
> > >>>>> When I said break up I meant mostly moving most everything outside
> of
> > >>>>> log4j-core,
> > >>>>> log4j-api, and log4j-plugins into separate repos such as
> > >>>>> logging-log4j-nosql,
> > >>>>> logging-log4j-pubsub, etc. These would not require groupId or
> > >>> artifactId
> > >>>>> changes
> > >>>>> although the versioning would potentially be out of synch with the
> > >> main
> > >>>>> releases
> > >>>>> as each would be on its own release cycle. This would greatly
> > >> simplify
> > >>>>> releasing
> > >>>>> core but it would require careful though on what the versions would
> > >> be
> > >>>> for
> > >>>>> the
> > >>>>> “extra” projects.
> > >>>>>
> > >>>>> As for further breaking up core, that should revolve primarily
> around
> > >>>>> reducing the
> > >>>>> dependencies listed in module-info.java to the bare minimum.
> > >>>>>
> > >>>>> There will be no log4j3. We cannot change groupIds, artifactIds, or
> > >>>>> package names,
> > >>>>> other than what has been done to support JPMS. A world in which a
> > >>> log4j2
> > >>>>> and
> > >>>>> log4j3 try to co-exist would be an unmitigated disaster. Commons
> can
> > >>>>> happily get
> > >>>>> away with that. Log4j cannot.
> > >>>>>
> > >>>>> If an application had both log4j2 and log4j3 jars present they
> would
> > >>> end
> > >>>>> up with
> > >>>>> multiple LoggerContexts, multiple Configurations, and multiple
> > >> Appender
> > >>>>> Managers
> > >>>>> where today there is only a single one. That would mean two
> instances
> > >>> of
> > >>>>> the same
> > >>>>> configuration file would be active at once. So when it is time to
> > >>>> rollover
> > >>>>> it would
> > >>>>> be performed twice instead of once as a simple example. For this
> > >> reason
> > >>>> we
> > >>>>> CANNOT break backward compatibility.
> > >>>>>
> > >>>>> However, we are talking about runtime backward compatibility. The
> > >>> Plugin
> > >>>>> system
> > >>>>> was changed internally in 3.0 so that plugins compiled with 3.0 use
> > >>>>> ServiceLoader
> > >>>>> instead of the data file. However, it will still find and use 2.x
> > >>> plugins
> > >>>>> when they are
> > >>>>> present and can be located.
> > >>>>>
> > >>>>> The meaning of this should be clear. It is 3.0 because to take
> > >>> advantage
> > >>>>> of its
> > >>>>> features you may have to make code changes. But it will tolerate
> code
> > >>>> that
> > >>>>> was
> > >>>>> compiled for 2.x.
> > >>>>>
> > >>>>> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
> > >>>>> 1. Plugins must be compiled with 3.0 to use the ServiceLoader
> > >>> packaging.
> > >>>>> 2. It requires Java 11. We still need to support Java 8.
> > >>>>> 3. It fully supports JPMS. Release 2.x does not. It is likely that
> > >>>>> applications with
> > >>>>> multiple Module Layers might not be able to find all the plugins.
> > >>> Adding
> > >>>>> full JPMS
> > >>>>> support to 2.x simply isn’t possible.
> > >>>>> 4. It will be introducing new DI injection features not present in
> > >> 2.x.
> > >>>>>
> > >>>>> Major releases do not imply that you are completely breaking
> backward
> > >>>>> compatibility.
> > >>>>> They imply that some kind of compatibility is broken, which we are
> > >>> doing
> > >>>>> by
> > >>>>> requiring coding changes to Plugins to compile with 3.0. This means
> > >> we
> > >>>>> need to
> > >>>>> leave in any classes or methods that existing plugins might have
> > >> used.
> > >>> It
> > >>>>> means
> > >>>>> we have to continue using our own Supplier unless it can be
> verified
> > >>> that
> > >>>>> an
> > >>>>> application using the Supplier in 2.x can run with 3.0 even if it
> is
> > >>>>> converted to
> > >>>>> java.util.function.Supplier. I have no idea if the code the
> compiler
> > >>>>> generates
> > >>>>> for lambdas actually implements the declared interface or not.
> > >>>>>
> > >>>>> Log4j 3.0 is a major change. But that doesn’t mean we can screw our
> > >>> users
> > >>>>> by
> > >>>>> breaking everything.
> > >>>>>
> > >>>>> Ralph
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> On Jun 10, 2021, at 6:32 AM, Gary Gregory <garydgregory@gmail.com
> >
> > >>>>> wrote:
> > >>>>>>
> > >>>>>> These are all IMOs of course, YMMV:
> > >>>>>> - What's the rush to 3.0?
> > >>>>>>
> > >>>>>> - I'm all for breaking up the core and other artifacts into more
> > >>>>>> artifacts based on their dependencies requirement such that
> > >> depending
> > >>>>>> on Log4j 3 does not "suck in the world", for example, I should be
> > >>> able
> > >>>>>> to depend on a currently non-existent "log4j3-console" and only
> > >> bring
> > >>>>>> in a tiny bit of code (API, a tiny core, and no plugin system). I
> > >> did
> > >>>>>> a fair amount of breaking up of various artifacts a while back.
> > >>>>>>
> > >>>>>> - 3.0 is a MAJOR release that gives us the opportunity to drop
> > >>>>>> deprecated APIs and code like our custom functional interfaces:
> > >>>>>> Supplier and so on. If we do not clean up, then there is no point
> > >> in
> > >>> a
> > >>>>>> major release. Basically, I expect to break binary and source
> > >>>>>> compatibility.
> > >>>>>>
> > >>>>>> - 3.0 must be in a new package namespace and new Maven
> > >> coordinates. I
> > >>>>>> MUST be able to run Log4j 1, 2, and 3 in the same class loader. I
> > >> can
> > >>>>>> already run Log4j 1 and 2 side by side which is good.
> > >>>>>>
> > >>>>>> Gary
> > >>>>>>
> > >>>>>> On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
> > >>> volkan.yazici@gmail.com
> > >>>>>
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>> Ralph, count me in for such a change. I really want to have
> > >> separate
> > >>>>>>> sub-projects for such modules. This will extremely speed up
> > >>>>> build/release
> > >>>>>>> times too, which is nowadays of uttermost importance to my peace
> > >> of
> > >>>> mind
> > >>>>>>> while developing.
> > >>>>>>>
> > >>>>>>> This said, I am reluctant about such a major change when we are
> > >> this
> > >>>>> close
> > >>>>>>> to the 3.0.0 release. I guess this would definitely postpone the
> > >>> 3.0.0
> > >>>>>>> release to 2022. This will probably break the backward
> > >> compatibility
> > >>>> at
> > >>>>>>> least for the artifact groupId, am I wrong? Not to mention that
> > >> the
> > >>>>> entire
> > >>>>>>> website needs to be adapted to this multi-project setup too. Is
> > >>> there
> > >>>>>>> anything else?
> > >>>>>>>
> > >>>>>>> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
> > >>>> ralph.goers@dslextreme.com>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Yeah - I have proposed moving all these extra integrations to a
> > >>>>> separate
> > >>>>>>>> repo but
> > >>>>>>>> I’ve never gotten consensus. I’d prefer to have a project like
> > >>>>>>>> log4j-pubsub where
> > >>>>>>>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all
> the
> > >>>> nosql
> > >>>>>>>> modules, etc.
> > >>>>>>>> The problem seems to be that some people believe that we would
> > >> have
> > >>>> to
> > >>>>> cut
> > >>>>>>>> a
> > >>>>>>>> release of those every time we do a log4j release.
> > >>>>>>>>
> > >>>>>>>> If we were to do that 3.0 would be the right time.
> > >>>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
> >
>
Re: Breaking up modules into separate sub-projects
Posted by Volkan Yazıcı <vo...@gmail.com>.
I agree with all the points (both pros and cons) you have shared.
A small "core" will speed up the development and release cycle
significantly. Most of the time I skip a full Maven "verify", which is
taking more than half an hour on my machine.
Regarding CI, I believe there will be a huge win too due to faster feedback
cycles. Also note that it is possible to trigger GitHub Actions workflows
from another repository change. Hence the consistency check across
repositories you have described can easily be set up.
On Fri, Jun 11, 2021 at 7:45 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> Not sure what you want a recap on. I see a few issues on both sides of the
> coin:
>
> For splitting:
> 1. Many of the current modules rarely get modified. Creating a new version
> of
> them with each release just so the release number matches seems silly.
> 2. Yes, creating a release is time consuming. When I am nearing the time to
> perform a release I:
> a. Review PRs and Jira issues looking for ones that are either critical,
> serious
> or easy to fix and try to address them. This typically involves
> running the
> build several times.
> b. Perform all the required release updates.
> c. Build the web site locally and inspect it.
> d. Follow the guide to actually perform the release.
> The prep time in step a is typically what takes the most time due to how
> many
> times I run the full build. This is where the most time savings would be
> since
> most of the changes occur in log4j-api and log4j-core, although the most
> time
> consuming part of the build is the log4j-core unit tests.
> 3. This might encourage everyone to run a full build for every commit.
>
> Against splitting:
> 1. Confusion over where a particular component can be found.
> 2. Although unlikely, it is possible a change in log4j-api or log4j-core
> could
> break something in one of the other modules and we wouldn’t find out
> immediately as we do today. This could be solved by setting up good
> Jenkins
> pipelines that cause all the sub projects to rebuild whenever the main
> module is built.
>
> Ralph
>
> > On Jun 11, 2021, at 10:12 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > I am on 100% board with spliting up modules/artifacts to reduce the "suck
> > the world in" issue. Splitting into separate repos/projects I have zero
> > interest in, I only see drawbacks. Version confusion, BOM POM or not,
> weird
> > dependeny issues, more fiddling with IDEs to make sure you can get stuff
> > done, bleh.
> >
> > I know Ralph has been quite generous with him time in release management
> > and has mentioned numerous time that he feels the current repository size
> > leads to long release candiate build times. But I see this as a drive to
> > break up the repository wrong headed. When I run any of the various Maven
> > builds I use, some builds rebuilds various pieces needlessly, compiling
> > code when no recompilation is needed for example, running tests more than
> > needed, and other Maven oddities. If the tooling is a problem, then lets
> > look at that first.
> >
> > Maybe we could get a recap from Ralph?
> >
> > Gary
> >
> >
> > On Fri, Jun 11, 2021, 10:42 Volkan Yazıcı <vo...@gmail.com>
> wrote:
> >
> >> Gary, I thought you were on board with breaking up into separate
> projects.
> >> What do you propose instead?
> >>
> >> On Fri, Jun 11, 2021 at 12:22 PM Gary Gregory <ga...@gmail.com>
> >> wrote:
> >>
> >>> From my POV, this will create an incomprehensible mess of versions for
> >>> users. Big bummer.
> >>>
> >>> Gary
> >>>
> >>> On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <vo...@gmail.com>
> >> wrote:
> >>>
> >>>> To start the discussion for breaking up the modules into separate
> >>> projects,
> >>>> I propose the following structure:
> >>>>
> >>>> *logging-log4j*
> >>>> log4j-1.2-api
> >>>> log4j-api
> >>>> log4j-bom
> >>>> log4j-core
> >>>> log4j-core-its
> >>>> log4j-gctests
> >>>> log4j-iostreams
> >>>> log4j-layout-template-json
> >>>> log4j-perf
> >>>> log4j-plugins
> >>>>
> >>>> *logging-log4j-appender*
> >>>> log4j-cassandra
> >>>> log4j-couchdb
> >>>> log4j-csv
> >>>> log4j-flume-ng
> >>>> log4j-mongodb3
> >>>> log4j-mongodb4
> >>>> log4j-smtp
> >>>>
> >>>> *logging-log4j-appender-jdbc*
> >>>> log4j-jdbc (?)
> >>>> log4j-jdbc-dbcp2 (?)
> >>>> log4j-jpa
> >>>>
> >>>> *logging-log4j-appender-queue*
> >>>> log4j-jeromq
> >>>> log4j-jms
> >>>> log4j-kafka
> >>>> log4j-redis
> >>>>
> >>>> *logging-log4j-binding*
> >>>> log4j-jcl
> >>>> log4j-jpl
> >>>> log4j-jul
> >>>> log4j-liquibase
> >>>> log4j-slf4j18-impl
> >>>> log4j-slf4j-impl
> >>>> log4j-to-slf4j
> >>>>
> >>>> *logging-log4j-container*
> >>>> log4j-docker
> >>>> log4j-kubernetes
> >>>>
> >>>> *logging-log4j-gui*
> >>>> log4j-jmx-gui
> >>>>
> >>>> *logging-log4j-jee*
> >>>> log4j-appserver
> >>>> log4j-taglib
> >>>> log4j-web
> >>>>
> >>>> *logging-log4j-layout-jackson*
> >>>> log4j-layout-jackson
> >>>> log4j-layout-jackson-json
> >>>> log4j-layout-jackson-xml
> >>>> log4j-layout-jackson-yaml
> >>>>
> >>>> *logging-log4j-osgi*
> >>>> log4j-osgi
> >>>>
> >>>> *logging-log4j-spring*
> >>>> log4j-spring-boot
> >>>> log4j-spring-cloud-config
> >>>>
> >>>> Note that above breakdown contains every available module in master,
> >>> except
> >>>> log4j-samples, which has the following sub-modules:
> >>>>
> >>>> log4j-samples-loggerProperties (contains 2 very trivial example
> >> classes,
> >>>> log4j-core [tests] contains more comprehensive alternatives)
> >>>> log4j-samples-flume-remote (flume-specific)
> >>>> log4j-samples-flume-embedded (flume-specific)
> >>>> log4j-samples-flume-common (flume-specific)
> >>>> log4j-samples-configuration (contains 3 very trivial example classes,
> >>>> log4j-core [tests] contains more comprehensive alternatives)
> >>>>
> >>>> I propose removing log4j-samples module and, if necessary, moving
> >>>> Flume-related parts to the log4j-flume-ng.
> >>>>
> >>>> I have kept log4j-layout-template-json in the logging-log4j project,
> >>> since
> >>>> it has no external dependencies. This said, I am okay with moving it
> >> to a
> >>>> separate logging-log4j-layout project.
> >>>>
> >>>> Please share your remarks. Eventually, I want to translate this into a
> >>> JIRA
> >>>> ticket.
> >>>>
> >>>> Kind regards.
> >>>>
> >>>> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <
> >> ralph.goers@dslextreme.com>
> >>>> wrote:
> >>>>
> >>>>> Gary,
> >>>>>
> >>>>> I am -1 to almost every item on your list.
> >>>>>
> >>>>> When I said break up I meant mostly moving most everything outside of
> >>>>> log4j-core,
> >>>>> log4j-api, and log4j-plugins into separate repos such as
> >>>>> logging-log4j-nosql,
> >>>>> logging-log4j-pubsub, etc. These would not require groupId or
> >>> artifactId
> >>>>> changes
> >>>>> although the versioning would potentially be out of synch with the
> >> main
> >>>>> releases
> >>>>> as each would be on its own release cycle. This would greatly
> >> simplify
> >>>>> releasing
> >>>>> core but it would require careful though on what the versions would
> >> be
> >>>> for
> >>>>> the
> >>>>> “extra” projects.
> >>>>>
> >>>>> As for further breaking up core, that should revolve primarily around
> >>>>> reducing the
> >>>>> dependencies listed in module-info.java to the bare minimum.
> >>>>>
> >>>>> There will be no log4j3. We cannot change groupIds, artifactIds, or
> >>>>> package names,
> >>>>> other than what has been done to support JPMS. A world in which a
> >>> log4j2
> >>>>> and
> >>>>> log4j3 try to co-exist would be an unmitigated disaster. Commons can
> >>>>> happily get
> >>>>> away with that. Log4j cannot.
> >>>>>
> >>>>> If an application had both log4j2 and log4j3 jars present they would
> >>> end
> >>>>> up with
> >>>>> multiple LoggerContexts, multiple Configurations, and multiple
> >> Appender
> >>>>> Managers
> >>>>> where today there is only a single one. That would mean two instances
> >>> of
> >>>>> the same
> >>>>> configuration file would be active at once. So when it is time to
> >>>> rollover
> >>>>> it would
> >>>>> be performed twice instead of once as a simple example. For this
> >> reason
> >>>> we
> >>>>> CANNOT break backward compatibility.
> >>>>>
> >>>>> However, we are talking about runtime backward compatibility. The
> >>> Plugin
> >>>>> system
> >>>>> was changed internally in 3.0 so that plugins compiled with 3.0 use
> >>>>> ServiceLoader
> >>>>> instead of the data file. However, it will still find and use 2.x
> >>> plugins
> >>>>> when they are
> >>>>> present and can be located.
> >>>>>
> >>>>> The meaning of this should be clear. It is 3.0 because to take
> >>> advantage
> >>>>> of its
> >>>>> features you may have to make code changes. But it will tolerate code
> >>>> that
> >>>>> was
> >>>>> compiled for 2.x.
> >>>>>
> >>>>> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
> >>>>> 1. Plugins must be compiled with 3.0 to use the ServiceLoader
> >>> packaging.
> >>>>> 2. It requires Java 11. We still need to support Java 8.
> >>>>> 3. It fully supports JPMS. Release 2.x does not. It is likely that
> >>>>> applications with
> >>>>> multiple Module Layers might not be able to find all the plugins.
> >>> Adding
> >>>>> full JPMS
> >>>>> support to 2.x simply isn’t possible.
> >>>>> 4. It will be introducing new DI injection features not present in
> >> 2.x.
> >>>>>
> >>>>> Major releases do not imply that you are completely breaking backward
> >>>>> compatibility.
> >>>>> They imply that some kind of compatibility is broken, which we are
> >>> doing
> >>>>> by
> >>>>> requiring coding changes to Plugins to compile with 3.0. This means
> >> we
> >>>>> need to
> >>>>> leave in any classes or methods that existing plugins might have
> >> used.
> >>> It
> >>>>> means
> >>>>> we have to continue using our own Supplier unless it can be verified
> >>> that
> >>>>> an
> >>>>> application using the Supplier in 2.x can run with 3.0 even if it is
> >>>>> converted to
> >>>>> java.util.function.Supplier. I have no idea if the code the compiler
> >>>>> generates
> >>>>> for lambdas actually implements the declared interface or not.
> >>>>>
> >>>>> Log4j 3.0 is a major change. But that doesn’t mean we can screw our
> >>> users
> >>>>> by
> >>>>> breaking everything.
> >>>>>
> >>>>> Ralph
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> These are all IMOs of course, YMMV:
> >>>>>> - What's the rush to 3.0?
> >>>>>>
> >>>>>> - I'm all for breaking up the core and other artifacts into more
> >>>>>> artifacts based on their dependencies requirement such that
> >> depending
> >>>>>> on Log4j 3 does not "suck in the world", for example, I should be
> >>> able
> >>>>>> to depend on a currently non-existent "log4j3-console" and only
> >> bring
> >>>>>> in a tiny bit of code (API, a tiny core, and no plugin system). I
> >> did
> >>>>>> a fair amount of breaking up of various artifacts a while back.
> >>>>>>
> >>>>>> - 3.0 is a MAJOR release that gives us the opportunity to drop
> >>>>>> deprecated APIs and code like our custom functional interfaces:
> >>>>>> Supplier and so on. If we do not clean up, then there is no point
> >> in
> >>> a
> >>>>>> major release. Basically, I expect to break binary and source
> >>>>>> compatibility.
> >>>>>>
> >>>>>> - 3.0 must be in a new package namespace and new Maven
> >> coordinates. I
> >>>>>> MUST be able to run Log4j 1, 2, and 3 in the same class loader. I
> >> can
> >>>>>> already run Log4j 1 and 2 side by side which is good.
> >>>>>>
> >>>>>> Gary
> >>>>>>
> >>>>>> On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
> >>> volkan.yazici@gmail.com
> >>>>>
> >>>>> wrote:
> >>>>>>>
> >>>>>>> Ralph, count me in for such a change. I really want to have
> >> separate
> >>>>>>> sub-projects for such modules. This will extremely speed up
> >>>>> build/release
> >>>>>>> times too, which is nowadays of uttermost importance to my peace
> >> of
> >>>> mind
> >>>>>>> while developing.
> >>>>>>>
> >>>>>>> This said, I am reluctant about such a major change when we are
> >> this
> >>>>> close
> >>>>>>> to the 3.0.0 release. I guess this would definitely postpone the
> >>> 3.0.0
> >>>>>>> release to 2022. This will probably break the backward
> >> compatibility
> >>>> at
> >>>>>>> least for the artifact groupId, am I wrong? Not to mention that
> >> the
> >>>>> entire
> >>>>>>> website needs to be adapted to this multi-project setup too. Is
> >>> there
> >>>>>>> anything else?
> >>>>>>>
> >>>>>>> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
> >>>> ralph.goers@dslextreme.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Yeah - I have proposed moving all these extra integrations to a
> >>>>> separate
> >>>>>>>> repo but
> >>>>>>>> I’ve never gotten consensus. I’d prefer to have a project like
> >>>>>>>> log4j-pubsub where
> >>>>>>>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
> >>>> nosql
> >>>>>>>> modules, etc.
> >>>>>>>> The problem seems to be that some people believe that we would
> >> have
> >>>> to
> >>>>> cut
> >>>>>>>> a
> >>>>>>>> release of those every time we do a log4j release.
> >>>>>>>>
> >>>>>>>> If we were to do that 3.0 would be the right time.
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
>
Re: Breaking up modules into separate sub-projects
Posted by Ralph Goers <ra...@dslextreme.com>.
Not sure what you want a recap on. I see a few issues on both sides of the coin:
For splitting:
1. Many of the current modules rarely get modified. Creating a new version of
them with each release just so the release number matches seems silly.
2. Yes, creating a release is time consuming. When I am nearing the time to
perform a release I:
a. Review PRs and Jira issues looking for ones that are either critical, serious
or easy to fix and try to address them. This typically involves running the
build several times.
b. Perform all the required release updates.
c. Build the web site locally and inspect it.
d. Follow the guide to actually perform the release.
The prep time in step a is typically what takes the most time due to how many
times I run the full build. This is where the most time savings would be since
most of the changes occur in log4j-api and log4j-core, although the most time
consuming part of the build is the log4j-core unit tests.
3. This might encourage everyone to run a full build for every commit.
Against splitting:
1. Confusion over where a particular component can be found.
2. Although unlikely, it is possible a change in log4j-api or log4j-core could
break something in one of the other modules and we wouldn’t find out
immediately as we do today. This could be solved by setting up good Jenkins
pipelines that cause all the sub projects to rebuild whenever the main module is built.
Ralph
> On Jun 11, 2021, at 10:12 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> I am on 100% board with spliting up modules/artifacts to reduce the "suck
> the world in" issue. Splitting into separate repos/projects I have zero
> interest in, I only see drawbacks. Version confusion, BOM POM or not, weird
> dependeny issues, more fiddling with IDEs to make sure you can get stuff
> done, bleh.
>
> I know Ralph has been quite generous with him time in release management
> and has mentioned numerous time that he feels the current repository size
> leads to long release candiate build times. But I see this as a drive to
> break up the repository wrong headed. When I run any of the various Maven
> builds I use, some builds rebuilds various pieces needlessly, compiling
> code when no recompilation is needed for example, running tests more than
> needed, and other Maven oddities. If the tooling is a problem, then lets
> look at that first.
>
> Maybe we could get a recap from Ralph?
>
> Gary
>
>
> On Fri, Jun 11, 2021, 10:42 Volkan Yazıcı <vo...@gmail.com> wrote:
>
>> Gary, I thought you were on board with breaking up into separate projects.
>> What do you propose instead?
>>
>> On Fri, Jun 11, 2021 at 12:22 PM Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> From my POV, this will create an incomprehensible mess of versions for
>>> users. Big bummer.
>>>
>>> Gary
>>>
>>> On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <vo...@gmail.com>
>> wrote:
>>>
>>>> To start the discussion for breaking up the modules into separate
>>> projects,
>>>> I propose the following structure:
>>>>
>>>> *logging-log4j*
>>>> log4j-1.2-api
>>>> log4j-api
>>>> log4j-bom
>>>> log4j-core
>>>> log4j-core-its
>>>> log4j-gctests
>>>> log4j-iostreams
>>>> log4j-layout-template-json
>>>> log4j-perf
>>>> log4j-plugins
>>>>
>>>> *logging-log4j-appender*
>>>> log4j-cassandra
>>>> log4j-couchdb
>>>> log4j-csv
>>>> log4j-flume-ng
>>>> log4j-mongodb3
>>>> log4j-mongodb4
>>>> log4j-smtp
>>>>
>>>> *logging-log4j-appender-jdbc*
>>>> log4j-jdbc (?)
>>>> log4j-jdbc-dbcp2 (?)
>>>> log4j-jpa
>>>>
>>>> *logging-log4j-appender-queue*
>>>> log4j-jeromq
>>>> log4j-jms
>>>> log4j-kafka
>>>> log4j-redis
>>>>
>>>> *logging-log4j-binding*
>>>> log4j-jcl
>>>> log4j-jpl
>>>> log4j-jul
>>>> log4j-liquibase
>>>> log4j-slf4j18-impl
>>>> log4j-slf4j-impl
>>>> log4j-to-slf4j
>>>>
>>>> *logging-log4j-container*
>>>> log4j-docker
>>>> log4j-kubernetes
>>>>
>>>> *logging-log4j-gui*
>>>> log4j-jmx-gui
>>>>
>>>> *logging-log4j-jee*
>>>> log4j-appserver
>>>> log4j-taglib
>>>> log4j-web
>>>>
>>>> *logging-log4j-layout-jackson*
>>>> log4j-layout-jackson
>>>> log4j-layout-jackson-json
>>>> log4j-layout-jackson-xml
>>>> log4j-layout-jackson-yaml
>>>>
>>>> *logging-log4j-osgi*
>>>> log4j-osgi
>>>>
>>>> *logging-log4j-spring*
>>>> log4j-spring-boot
>>>> log4j-spring-cloud-config
>>>>
>>>> Note that above breakdown contains every available module in master,
>>> except
>>>> log4j-samples, which has the following sub-modules:
>>>>
>>>> log4j-samples-loggerProperties (contains 2 very trivial example
>> classes,
>>>> log4j-core [tests] contains more comprehensive alternatives)
>>>> log4j-samples-flume-remote (flume-specific)
>>>> log4j-samples-flume-embedded (flume-specific)
>>>> log4j-samples-flume-common (flume-specific)
>>>> log4j-samples-configuration (contains 3 very trivial example classes,
>>>> log4j-core [tests] contains more comprehensive alternatives)
>>>>
>>>> I propose removing log4j-samples module and, if necessary, moving
>>>> Flume-related parts to the log4j-flume-ng.
>>>>
>>>> I have kept log4j-layout-template-json in the logging-log4j project,
>>> since
>>>> it has no external dependencies. This said, I am okay with moving it
>> to a
>>>> separate logging-log4j-layout project.
>>>>
>>>> Please share your remarks. Eventually, I want to translate this into a
>>> JIRA
>>>> ticket.
>>>>
>>>> Kind regards.
>>>>
>>>> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <
>> ralph.goers@dslextreme.com>
>>>> wrote:
>>>>
>>>>> Gary,
>>>>>
>>>>> I am -1 to almost every item on your list.
>>>>>
>>>>> When I said break up I meant mostly moving most everything outside of
>>>>> log4j-core,
>>>>> log4j-api, and log4j-plugins into separate repos such as
>>>>> logging-log4j-nosql,
>>>>> logging-log4j-pubsub, etc. These would not require groupId or
>>> artifactId
>>>>> changes
>>>>> although the versioning would potentially be out of synch with the
>> main
>>>>> releases
>>>>> as each would be on its own release cycle. This would greatly
>> simplify
>>>>> releasing
>>>>> core but it would require careful though on what the versions would
>> be
>>>> for
>>>>> the
>>>>> “extra” projects.
>>>>>
>>>>> As for further breaking up core, that should revolve primarily around
>>>>> reducing the
>>>>> dependencies listed in module-info.java to the bare minimum.
>>>>>
>>>>> There will be no log4j3. We cannot change groupIds, artifactIds, or
>>>>> package names,
>>>>> other than what has been done to support JPMS. A world in which a
>>> log4j2
>>>>> and
>>>>> log4j3 try to co-exist would be an unmitigated disaster. Commons can
>>>>> happily get
>>>>> away with that. Log4j cannot.
>>>>>
>>>>> If an application had both log4j2 and log4j3 jars present they would
>>> end
>>>>> up with
>>>>> multiple LoggerContexts, multiple Configurations, and multiple
>> Appender
>>>>> Managers
>>>>> where today there is only a single one. That would mean two instances
>>> of
>>>>> the same
>>>>> configuration file would be active at once. So when it is time to
>>>> rollover
>>>>> it would
>>>>> be performed twice instead of once as a simple example. For this
>> reason
>>>> we
>>>>> CANNOT break backward compatibility.
>>>>>
>>>>> However, we are talking about runtime backward compatibility. The
>>> Plugin
>>>>> system
>>>>> was changed internally in 3.0 so that plugins compiled with 3.0 use
>>>>> ServiceLoader
>>>>> instead of the data file. However, it will still find and use 2.x
>>> plugins
>>>>> when they are
>>>>> present and can be located.
>>>>>
>>>>> The meaning of this should be clear. It is 3.0 because to take
>>> advantage
>>>>> of its
>>>>> features you may have to make code changes. But it will tolerate code
>>>> that
>>>>> was
>>>>> compiled for 2.x.
>>>>>
>>>>> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
>>>>> 1. Plugins must be compiled with 3.0 to use the ServiceLoader
>>> packaging.
>>>>> 2. It requires Java 11. We still need to support Java 8.
>>>>> 3. It fully supports JPMS. Release 2.x does not. It is likely that
>>>>> applications with
>>>>> multiple Module Layers might not be able to find all the plugins.
>>> Adding
>>>>> full JPMS
>>>>> support to 2.x simply isn’t possible.
>>>>> 4. It will be introducing new DI injection features not present in
>> 2.x.
>>>>>
>>>>> Major releases do not imply that you are completely breaking backward
>>>>> compatibility.
>>>>> They imply that some kind of compatibility is broken, which we are
>>> doing
>>>>> by
>>>>> requiring coding changes to Plugins to compile with 3.0. This means
>> we
>>>>> need to
>>>>> leave in any classes or methods that existing plugins might have
>> used.
>>> It
>>>>> means
>>>>> we have to continue using our own Supplier unless it can be verified
>>> that
>>>>> an
>>>>> application using the Supplier in 2.x can run with 3.0 even if it is
>>>>> converted to
>>>>> java.util.function.Supplier. I have no idea if the code the compiler
>>>>> generates
>>>>> for lambdas actually implements the declared interface or not.
>>>>>
>>>>> Log4j 3.0 is a major change. But that doesn’t mean we can screw our
>>> users
>>>>> by
>>>>> breaking everything.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>
>>>>>> On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> These are all IMOs of course, YMMV:
>>>>>> - What's the rush to 3.0?
>>>>>>
>>>>>> - I'm all for breaking up the core and other artifacts into more
>>>>>> artifacts based on their dependencies requirement such that
>> depending
>>>>>> on Log4j 3 does not "suck in the world", for example, I should be
>>> able
>>>>>> to depend on a currently non-existent "log4j3-console" and only
>> bring
>>>>>> in a tiny bit of code (API, a tiny core, and no plugin system). I
>> did
>>>>>> a fair amount of breaking up of various artifacts a while back.
>>>>>>
>>>>>> - 3.0 is a MAJOR release that gives us the opportunity to drop
>>>>>> deprecated APIs and code like our custom functional interfaces:
>>>>>> Supplier and so on. If we do not clean up, then there is no point
>> in
>>> a
>>>>>> major release. Basically, I expect to break binary and source
>>>>>> compatibility.
>>>>>>
>>>>>> - 3.0 must be in a new package namespace and new Maven
>> coordinates. I
>>>>>> MUST be able to run Log4j 1, 2, and 3 in the same class loader. I
>> can
>>>>>> already run Log4j 1 and 2 side by side which is good.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
>>> volkan.yazici@gmail.com
>>>>>
>>>>> wrote:
>>>>>>>
>>>>>>> Ralph, count me in for such a change. I really want to have
>> separate
>>>>>>> sub-projects for such modules. This will extremely speed up
>>>>> build/release
>>>>>>> times too, which is nowadays of uttermost importance to my peace
>> of
>>>> mind
>>>>>>> while developing.
>>>>>>>
>>>>>>> This said, I am reluctant about such a major change when we are
>> this
>>>>> close
>>>>>>> to the 3.0.0 release. I guess this would definitely postpone the
>>> 3.0.0
>>>>>>> release to 2022. This will probably break the backward
>> compatibility
>>>> at
>>>>>>> least for the artifact groupId, am I wrong? Not to mention that
>> the
>>>>> entire
>>>>>>> website needs to be adapted to this multi-project setup too. Is
>>> there
>>>>>>> anything else?
>>>>>>>
>>>>>>> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
>>>> ralph.goers@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yeah - I have proposed moving all these extra integrations to a
>>>>> separate
>>>>>>>> repo but
>>>>>>>> I’ve never gotten consensus. I’d prefer to have a project like
>>>>>>>> log4j-pubsub where
>>>>>>>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
>>>> nosql
>>>>>>>> modules, etc.
>>>>>>>> The problem seems to be that some people believe that we would
>> have
>>>> to
>>>>> cut
>>>>>>>> a
>>>>>>>> release of those every time we do a log4j release.
>>>>>>>>
>>>>>>>> If we were to do that 3.0 would be the right time.
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
Re: Breaking up modules into separate sub-projects
Posted by Gary Gregory <ga...@gmail.com>.
I am on 100% board with spliting up modules/artifacts to reduce the "suck
the world in" issue. Splitting into separate repos/projects I have zero
interest in, I only see drawbacks. Version confusion, BOM POM or not, weird
dependeny issues, more fiddling with IDEs to make sure you can get stuff
done, bleh.
I know Ralph has been quite generous with him time in release management
and has mentioned numerous time that he feels the current repository size
leads to long release candiate build times. But I see this as a drive to
break up the repository wrong headed. When I run any of the various Maven
builds I use, some builds rebuilds various pieces needlessly, compiling
code when no recompilation is needed for example, running tests more than
needed, and other Maven oddities. If the tooling is a problem, then lets
look at that first.
Maybe we could get a recap from Ralph?
Gary
On Fri, Jun 11, 2021, 10:42 Volkan Yazıcı <vo...@gmail.com> wrote:
> Gary, I thought you were on board with breaking up into separate projects.
> What do you propose instead?
>
> On Fri, Jun 11, 2021 at 12:22 PM Gary Gregory <ga...@gmail.com>
> wrote:
>
> > From my POV, this will create an incomprehensible mess of versions for
> > users. Big bummer.
> >
> > Gary
> >
> > On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <vo...@gmail.com>
> wrote:
> >
> > > To start the discussion for breaking up the modules into separate
> > projects,
> > > I propose the following structure:
> > >
> > > *logging-log4j*
> > > log4j-1.2-api
> > > log4j-api
> > > log4j-bom
> > > log4j-core
> > > log4j-core-its
> > > log4j-gctests
> > > log4j-iostreams
> > > log4j-layout-template-json
> > > log4j-perf
> > > log4j-plugins
> > >
> > > *logging-log4j-appender*
> > > log4j-cassandra
> > > log4j-couchdb
> > > log4j-csv
> > > log4j-flume-ng
> > > log4j-mongodb3
> > > log4j-mongodb4
> > > log4j-smtp
> > >
> > > *logging-log4j-appender-jdbc*
> > > log4j-jdbc (?)
> > > log4j-jdbc-dbcp2 (?)
> > > log4j-jpa
> > >
> > > *logging-log4j-appender-queue*
> > > log4j-jeromq
> > > log4j-jms
> > > log4j-kafka
> > > log4j-redis
> > >
> > > *logging-log4j-binding*
> > > log4j-jcl
> > > log4j-jpl
> > > log4j-jul
> > > log4j-liquibase
> > > log4j-slf4j18-impl
> > > log4j-slf4j-impl
> > > log4j-to-slf4j
> > >
> > > *logging-log4j-container*
> > > log4j-docker
> > > log4j-kubernetes
> > >
> > > *logging-log4j-gui*
> > > log4j-jmx-gui
> > >
> > > *logging-log4j-jee*
> > > log4j-appserver
> > > log4j-taglib
> > > log4j-web
> > >
> > > *logging-log4j-layout-jackson*
> > > log4j-layout-jackson
> > > log4j-layout-jackson-json
> > > log4j-layout-jackson-xml
> > > log4j-layout-jackson-yaml
> > >
> > > *logging-log4j-osgi*
> > > log4j-osgi
> > >
> > > *logging-log4j-spring*
> > > log4j-spring-boot
> > > log4j-spring-cloud-config
> > >
> > > Note that above breakdown contains every available module in master,
> > except
> > > log4j-samples, which has the following sub-modules:
> > >
> > > log4j-samples-loggerProperties (contains 2 very trivial example
> classes,
> > > log4j-core [tests] contains more comprehensive alternatives)
> > > log4j-samples-flume-remote (flume-specific)
> > > log4j-samples-flume-embedded (flume-specific)
> > > log4j-samples-flume-common (flume-specific)
> > > log4j-samples-configuration (contains 3 very trivial example classes,
> > > log4j-core [tests] contains more comprehensive alternatives)
> > >
> > > I propose removing log4j-samples module and, if necessary, moving
> > > Flume-related parts to the log4j-flume-ng.
> > >
> > > I have kept log4j-layout-template-json in the logging-log4j project,
> > since
> > > it has no external dependencies. This said, I am okay with moving it
> to a
> > > separate logging-log4j-layout project.
> > >
> > > Please share your remarks. Eventually, I want to translate this into a
> > JIRA
> > > ticket.
> > >
> > > Kind regards.
> > >
> > > On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <
> ralph.goers@dslextreme.com>
> > > wrote:
> > >
> > > > Gary,
> > > >
> > > > I am -1 to almost every item on your list.
> > > >
> > > > When I said break up I meant mostly moving most everything outside of
> > > > log4j-core,
> > > > log4j-api, and log4j-plugins into separate repos such as
> > > > logging-log4j-nosql,
> > > > logging-log4j-pubsub, etc. These would not require groupId or
> > artifactId
> > > > changes
> > > > although the versioning would potentially be out of synch with the
> main
> > > > releases
> > > > as each would be on its own release cycle. This would greatly
> simplify
> > > > releasing
> > > > core but it would require careful though on what the versions would
> be
> > > for
> > > > the
> > > > “extra” projects.
> > > >
> > > > As for further breaking up core, that should revolve primarily around
> > > > reducing the
> > > > dependencies listed in module-info.java to the bare minimum.
> > > >
> > > > There will be no log4j3. We cannot change groupIds, artifactIds, or
> > > > package names,
> > > > other than what has been done to support JPMS. A world in which a
> > log4j2
> > > > and
> > > > log4j3 try to co-exist would be an unmitigated disaster. Commons can
> > > > happily get
> > > > away with that. Log4j cannot.
> > > >
> > > > If an application had both log4j2 and log4j3 jars present they would
> > end
> > > > up with
> > > > multiple LoggerContexts, multiple Configurations, and multiple
> Appender
> > > > Managers
> > > > where today there is only a single one. That would mean two instances
> > of
> > > > the same
> > > > configuration file would be active at once. So when it is time to
> > > rollover
> > > > it would
> > > > be performed twice instead of once as a simple example. For this
> reason
> > > we
> > > > CANNOT break backward compatibility.
> > > >
> > > > However, we are talking about runtime backward compatibility. The
> > Plugin
> > > > system
> > > > was changed internally in 3.0 so that plugins compiled with 3.0 use
> > > > ServiceLoader
> > > > instead of the data file. However, it will still find and use 2.x
> > plugins
> > > > when they are
> > > > present and can be located.
> > > >
> > > > The meaning of this should be clear. It is 3.0 because to take
> > advantage
> > > > of its
> > > > features you may have to make code changes. But it will tolerate code
> > > that
> > > > was
> > > > compiled for 2.x.
> > > >
> > > > The reasons why it is 3.0 and not a simple upgrade to 2.x are:
> > > > 1. Plugins must be compiled with 3.0 to use the ServiceLoader
> > packaging.
> > > > 2. It requires Java 11. We still need to support Java 8.
> > > > 3. It fully supports JPMS. Release 2.x does not. It is likely that
> > > > applications with
> > > > multiple Module Layers might not be able to find all the plugins.
> > Adding
> > > > full JPMS
> > > > support to 2.x simply isn’t possible.
> > > > 4. It will be introducing new DI injection features not present in
> 2.x.
> > > >
> > > > Major releases do not imply that you are completely breaking backward
> > > > compatibility.
> > > > They imply that some kind of compatibility is broken, which we are
> > doing
> > > > by
> > > > requiring coding changes to Plugins to compile with 3.0. This means
> we
> > > > need to
> > > > leave in any classes or methods that existing plugins might have
> used.
> > It
> > > > means
> > > > we have to continue using our own Supplier unless it can be verified
> > that
> > > > an
> > > > application using the Supplier in 2.x can run with 3.0 even if it is
> > > > converted to
> > > > java.util.function.Supplier. I have no idea if the code the compiler
> > > > generates
> > > > for lambdas actually implements the declared interface or not.
> > > >
> > > > Log4j 3.0 is a major change. But that doesn’t mean we can screw our
> > users
> > > > by
> > > > breaking everything.
> > > >
> > > > Ralph
> > > >
> > > >
> > > >
> > > > > On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
> > > > wrote:
> > > > >
> > > > > These are all IMOs of course, YMMV:
> > > > > - What's the rush to 3.0?
> > > > >
> > > > > - I'm all for breaking up the core and other artifacts into more
> > > > > artifacts based on their dependencies requirement such that
> depending
> > > > > on Log4j 3 does not "suck in the world", for example, I should be
> > able
> > > > > to depend on a currently non-existent "log4j3-console" and only
> bring
> > > > > in a tiny bit of code (API, a tiny core, and no plugin system). I
> did
> > > > > a fair amount of breaking up of various artifacts a while back.
> > > > >
> > > > > - 3.0 is a MAJOR release that gives us the opportunity to drop
> > > > > deprecated APIs and code like our custom functional interfaces:
> > > > > Supplier and so on. If we do not clean up, then there is no point
> in
> > a
> > > > > major release. Basically, I expect to break binary and source
> > > > > compatibility.
> > > > >
> > > > > - 3.0 must be in a new package namespace and new Maven
> coordinates. I
> > > > > MUST be able to run Log4j 1, 2, and 3 in the same class loader. I
> can
> > > > > already run Log4j 1 and 2 side by side which is good.
> > > > >
> > > > > Gary
> > > > >
> > > > > On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
> > volkan.yazici@gmail.com
> > > >
> > > > wrote:
> > > > >>
> > > > >> Ralph, count me in for such a change. I really want to have
> separate
> > > > >> sub-projects for such modules. This will extremely speed up
> > > > build/release
> > > > >> times too, which is nowadays of uttermost importance to my peace
> of
> > > mind
> > > > >> while developing.
> > > > >>
> > > > >> This said, I am reluctant about such a major change when we are
> this
> > > > close
> > > > >> to the 3.0.0 release. I guess this would definitely postpone the
> > 3.0.0
> > > > >> release to 2022. This will probably break the backward
> compatibility
> > > at
> > > > >> least for the artifact groupId, am I wrong? Not to mention that
> the
> > > > entire
> > > > >> website needs to be adapted to this multi-project setup too. Is
> > there
> > > > >> anything else?
> > > > >>
> > > > >> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
> > > ralph.goers@dslextreme.com>
> > > > >> wrote:
> > > > >>
> > > > >>> Yeah - I have proposed moving all these extra integrations to a
> > > > separate
> > > > >>> repo but
> > > > >>> I’ve never gotten consensus. I’d prefer to have a project like
> > > > >>> log4j-pubsub where
> > > > >>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
> > > nosql
> > > > >>> modules, etc.
> > > > >>> The problem seems to be that some people believe that we would
> have
> > > to
> > > > cut
> > > > >>> a
> > > > >>> release of those every time we do a log4j release.
> > > > >>>
> > > > >>> If we were to do that 3.0 would be the right time.
> > > > >>>
> > > > >
> > > >
> > > >
> > > >
> > >
> >
>
Re: Breaking up modules into separate sub-projects
Posted by Volkan Yazıcı <vo...@gmail.com>.
Gary, I thought you were on board with breaking up into separate projects.
What do you propose instead?
On Fri, Jun 11, 2021 at 12:22 PM Gary Gregory <ga...@gmail.com>
wrote:
> From my POV, this will create an incomprehensible mess of versions for
> users. Big bummer.
>
> Gary
>
> On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <vo...@gmail.com> wrote:
>
> > To start the discussion for breaking up the modules into separate
> projects,
> > I propose the following structure:
> >
> > *logging-log4j*
> > log4j-1.2-api
> > log4j-api
> > log4j-bom
> > log4j-core
> > log4j-core-its
> > log4j-gctests
> > log4j-iostreams
> > log4j-layout-template-json
> > log4j-perf
> > log4j-plugins
> >
> > *logging-log4j-appender*
> > log4j-cassandra
> > log4j-couchdb
> > log4j-csv
> > log4j-flume-ng
> > log4j-mongodb3
> > log4j-mongodb4
> > log4j-smtp
> >
> > *logging-log4j-appender-jdbc*
> > log4j-jdbc (?)
> > log4j-jdbc-dbcp2 (?)
> > log4j-jpa
> >
> > *logging-log4j-appender-queue*
> > log4j-jeromq
> > log4j-jms
> > log4j-kafka
> > log4j-redis
> >
> > *logging-log4j-binding*
> > log4j-jcl
> > log4j-jpl
> > log4j-jul
> > log4j-liquibase
> > log4j-slf4j18-impl
> > log4j-slf4j-impl
> > log4j-to-slf4j
> >
> > *logging-log4j-container*
> > log4j-docker
> > log4j-kubernetes
> >
> > *logging-log4j-gui*
> > log4j-jmx-gui
> >
> > *logging-log4j-jee*
> > log4j-appserver
> > log4j-taglib
> > log4j-web
> >
> > *logging-log4j-layout-jackson*
> > log4j-layout-jackson
> > log4j-layout-jackson-json
> > log4j-layout-jackson-xml
> > log4j-layout-jackson-yaml
> >
> > *logging-log4j-osgi*
> > log4j-osgi
> >
> > *logging-log4j-spring*
> > log4j-spring-boot
> > log4j-spring-cloud-config
> >
> > Note that above breakdown contains every available module in master,
> except
> > log4j-samples, which has the following sub-modules:
> >
> > log4j-samples-loggerProperties (contains 2 very trivial example classes,
> > log4j-core [tests] contains more comprehensive alternatives)
> > log4j-samples-flume-remote (flume-specific)
> > log4j-samples-flume-embedded (flume-specific)
> > log4j-samples-flume-common (flume-specific)
> > log4j-samples-configuration (contains 3 very trivial example classes,
> > log4j-core [tests] contains more comprehensive alternatives)
> >
> > I propose removing log4j-samples module and, if necessary, moving
> > Flume-related parts to the log4j-flume-ng.
> >
> > I have kept log4j-layout-template-json in the logging-log4j project,
> since
> > it has no external dependencies. This said, I am okay with moving it to a
> > separate logging-log4j-layout project.
> >
> > Please share your remarks. Eventually, I want to translate this into a
> JIRA
> > ticket.
> >
> > Kind regards.
> >
> > On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> > > Gary,
> > >
> > > I am -1 to almost every item on your list.
> > >
> > > When I said break up I meant mostly moving most everything outside of
> > > log4j-core,
> > > log4j-api, and log4j-plugins into separate repos such as
> > > logging-log4j-nosql,
> > > logging-log4j-pubsub, etc. These would not require groupId or
> artifactId
> > > changes
> > > although the versioning would potentially be out of synch with the main
> > > releases
> > > as each would be on its own release cycle. This would greatly simplify
> > > releasing
> > > core but it would require careful though on what the versions would be
> > for
> > > the
> > > “extra” projects.
> > >
> > > As for further breaking up core, that should revolve primarily around
> > > reducing the
> > > dependencies listed in module-info.java to the bare minimum.
> > >
> > > There will be no log4j3. We cannot change groupIds, artifactIds, or
> > > package names,
> > > other than what has been done to support JPMS. A world in which a
> log4j2
> > > and
> > > log4j3 try to co-exist would be an unmitigated disaster. Commons can
> > > happily get
> > > away with that. Log4j cannot.
> > >
> > > If an application had both log4j2 and log4j3 jars present they would
> end
> > > up with
> > > multiple LoggerContexts, multiple Configurations, and multiple Appender
> > > Managers
> > > where today there is only a single one. That would mean two instances
> of
> > > the same
> > > configuration file would be active at once. So when it is time to
> > rollover
> > > it would
> > > be performed twice instead of once as a simple example. For this reason
> > we
> > > CANNOT break backward compatibility.
> > >
> > > However, we are talking about runtime backward compatibility. The
> Plugin
> > > system
> > > was changed internally in 3.0 so that plugins compiled with 3.0 use
> > > ServiceLoader
> > > instead of the data file. However, it will still find and use 2.x
> plugins
> > > when they are
> > > present and can be located.
> > >
> > > The meaning of this should be clear. It is 3.0 because to take
> advantage
> > > of its
> > > features you may have to make code changes. But it will tolerate code
> > that
> > > was
> > > compiled for 2.x.
> > >
> > > The reasons why it is 3.0 and not a simple upgrade to 2.x are:
> > > 1. Plugins must be compiled with 3.0 to use the ServiceLoader
> packaging.
> > > 2. It requires Java 11. We still need to support Java 8.
> > > 3. It fully supports JPMS. Release 2.x does not. It is likely that
> > > applications with
> > > multiple Module Layers might not be able to find all the plugins.
> Adding
> > > full JPMS
> > > support to 2.x simply isn’t possible.
> > > 4. It will be introducing new DI injection features not present in 2.x.
> > >
> > > Major releases do not imply that you are completely breaking backward
> > > compatibility.
> > > They imply that some kind of compatibility is broken, which we are
> doing
> > > by
> > > requiring coding changes to Plugins to compile with 3.0. This means we
> > > need to
> > > leave in any classes or methods that existing plugins might have used.
> It
> > > means
> > > we have to continue using our own Supplier unless it can be verified
> that
> > > an
> > > application using the Supplier in 2.x can run with 3.0 even if it is
> > > converted to
> > > java.util.function.Supplier. I have no idea if the code the compiler
> > > generates
> > > for lambdas actually implements the declared interface or not.
> > >
> > > Log4j 3.0 is a major change. But that doesn’t mean we can screw our
> users
> > > by
> > > breaking everything.
> > >
> > > Ralph
> > >
> > >
> > >
> > > > On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
> > > wrote:
> > > >
> > > > These are all IMOs of course, YMMV:
> > > > - What's the rush to 3.0?
> > > >
> > > > - I'm all for breaking up the core and other artifacts into more
> > > > artifacts based on their dependencies requirement such that depending
> > > > on Log4j 3 does not "suck in the world", for example, I should be
> able
> > > > to depend on a currently non-existent "log4j3-console" and only bring
> > > > in a tiny bit of code (API, a tiny core, and no plugin system). I did
> > > > a fair amount of breaking up of various artifacts a while back.
> > > >
> > > > - 3.0 is a MAJOR release that gives us the opportunity to drop
> > > > deprecated APIs and code like our custom functional interfaces:
> > > > Supplier and so on. If we do not clean up, then there is no point in
> a
> > > > major release. Basically, I expect to break binary and source
> > > > compatibility.
> > > >
> > > > - 3.0 must be in a new package namespace and new Maven coordinates. I
> > > > MUST be able to run Log4j 1, 2, and 3 in the same class loader. I can
> > > > already run Log4j 1 and 2 side by side which is good.
> > > >
> > > > Gary
> > > >
> > > > On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
> volkan.yazici@gmail.com
> > >
> > > wrote:
> > > >>
> > > >> Ralph, count me in for such a change. I really want to have separate
> > > >> sub-projects for such modules. This will extremely speed up
> > > build/release
> > > >> times too, which is nowadays of uttermost importance to my peace of
> > mind
> > > >> while developing.
> > > >>
> > > >> This said, I am reluctant about such a major change when we are this
> > > close
> > > >> to the 3.0.0 release. I guess this would definitely postpone the
> 3.0.0
> > > >> release to 2022. This will probably break the backward compatibility
> > at
> > > >> least for the artifact groupId, am I wrong? Not to mention that the
> > > entire
> > > >> website needs to be adapted to this multi-project setup too. Is
> there
> > > >> anything else?
> > > >>
> > > >> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
> > ralph.goers@dslextreme.com>
> > > >> wrote:
> > > >>
> > > >>> Yeah - I have proposed moving all these extra integrations to a
> > > separate
> > > >>> repo but
> > > >>> I’ve never gotten consensus. I’d prefer to have a project like
> > > >>> log4j-pubsub where
> > > >>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
> > nosql
> > > >>> modules, etc.
> > > >>> The problem seems to be that some people believe that we would have
> > to
> > > cut
> > > >>> a
> > > >>> release of those every time we do a log4j release.
> > > >>>
> > > >>> If we were to do that 3.0 would be the right time.
> > > >>>
> > > >
> > >
> > >
> > >
> >
>
Re: Breaking up modules into separate sub-projects
Posted by Ralph Goers <ra...@dslextreme.com>.
But why would we do this? What advantage does it have over just including
the bom pom.xml in the main project? Surely we will have many more releases
of that than any of the sub-projects? If each release has an up-to-date bom
pom.xml then it is actually fulfilling its purpose.
Ralph
> On Jun 11, 2021, at 8:47 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> Right, a release train BOM would be its own repo basically for making
> periodic dependency update releases (typically can be done around the
> same time as the referenced components being released). Release trains
> could either be a single log4j train or multiple trains like how
> Spring has multiple projects (probably too much overhead for us?).
>
> On Fri, 11 Jun 2021 at 10:44, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> I agree with you there. Gary is correct that it would be difficult for users to
>> keep track of all of this without such a mechanism. The fact is though that
>> we already have it. The log4j-bom pom.xml is already included in every
>> log4j release. We simply have to ensure that it always contains the correct
>> versions of the artifacts.
>>
>> If we did this though, it might make more sense for every project to have
>> its own bill of materials pom.xml and for the main log4j bom to import all of
>> those instead of naming every individual artifact.
>>
>> If we do this I would suggest that we also consider the impact to the web
>> site. I would not want to see all of these have their own web sites but
>> continue to be integrated into the main web site. At the same time though,
>> we would need to make it easy for users to locate the git repos for the
>> components they are looking for. GitHub’s search mechanism doesn’t make
>> it easy to find only the Apache logging projects, let alone just those related
>> to log4j.
>>
>> I would also suggest that no matter what we do we will have to consider the
>> impact to the web site if both release-2.x and master are being supported.
>> We could imitate Tomcat and have a main web site that links to prior
>> versions or we could try to modify the 3.0 web site to document what is new
>> and different while keeping the doc for 2.x.
>>
>> I will admit though, that although Spring does this fairly successfully their
>> process is a bit different than what I am imagining here. Every Spring component
>> releases on its own schedule. Periodically Spring Boot and Sprint Cloud each
>> have their own releases of all the components packaged together. In Log4j
>> terms that would essentially mean that the log4j-bom project would be extracted
>> from the main project and periodically it would be released all by itself.
>>
>> Ralph
>>
>>> On Jun 11, 2021, at 7:43 AM, Volkan Yazıcı <vo...@gmail.com> wrote:
>>>
>>> I definitely agree with this. This is such a convenience while using Spring.
>>>
>>> On Fri, Jun 11, 2021 at 4:07 PM Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> If we end up breaking up the modules and releasing them independently, I
>>>> suggest we also adopt a release train mechanism to collect them together
>>>> into single version BOM-style POM files. Also, if independent releases are
>>>> faster to make and faster to verify, then we can make them more often.
>>>>
>>>> On Fri, Jun 11, 2021 at 05:22 Gary Gregory <ga...@gmail.com> wrote:
>>>>
>>>>> From my POV, this will create an incomprehensible mess of versions for
>>>>> users. Big bummer.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <vo...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> To start the discussion for breaking up the modules into separate
>>>>> projects,
>>>>>> I propose the following structure:
>>>>>>
>>>>>> *logging-log4j*
>>>>>> log4j-1.2-api
>>>>>> log4j-api
>>>>>> log4j-bom
>>>>>> log4j-core
>>>>>> log4j-core-its
>>>>>> log4j-gctests
>>>>>> log4j-iostreams
>>>>>> log4j-layout-template-json
>>>>>> log4j-perf
>>>>>> log4j-plugins
>>>>>>
>>>>>> *logging-log4j-appender*
>>>>>> log4j-cassandra
>>>>>> log4j-couchdb
>>>>>> log4j-csv
>>>>>> log4j-flume-ng
>>>>>> log4j-mongodb3
>>>>>> log4j-mongodb4
>>>>>> log4j-smtp
>>>>>>
>>>>>> *logging-log4j-appender-jdbc*
>>>>>> log4j-jdbc (?)
>>>>>> log4j-jdbc-dbcp2 (?)
>>>>>> log4j-jpa
>>>>>>
>>>>>> *logging-log4j-appender-queue*
>>>>>> log4j-jeromq
>>>>>> log4j-jms
>>>>>> log4j-kafka
>>>>>> log4j-redis
>>>>>>
>>>>>> *logging-log4j-binding*
>>>>>> log4j-jcl
>>>>>> log4j-jpl
>>>>>> log4j-jul
>>>>>> log4j-liquibase
>>>>>> log4j-slf4j18-impl
>>>>>> log4j-slf4j-impl
>>>>>> log4j-to-slf4j
>>>>>>
>>>>>> *logging-log4j-container*
>>>>>> log4j-docker
>>>>>> log4j-kubernetes
>>>>>>
>>>>>> *logging-log4j-gui*
>>>>>> log4j-jmx-gui
>>>>>>
>>>>>> *logging-log4j-jee*
>>>>>> log4j-appserver
>>>>>> log4j-taglib
>>>>>> log4j-web
>>>>>>
>>>>>> *logging-log4j-layout-jackson*
>>>>>> log4j-layout-jackson
>>>>>> log4j-layout-jackson-json
>>>>>> log4j-layout-jackson-xml
>>>>>> log4j-layout-jackson-yaml
>>>>>>
>>>>>> *logging-log4j-osgi*
>>>>>> log4j-osgi
>>>>>>
>>>>>> *logging-log4j-spring*
>>>>>> log4j-spring-boot
>>>>>> log4j-spring-cloud-config
>>>>>>
>>>>>> Note that above breakdown contains every available module in master,
>>>>> except
>>>>>> log4j-samples, which has the following sub-modules:
>>>>>>
>>>>>> log4j-samples-loggerProperties (contains 2 very trivial example
>>>> classes,
>>>>>> log4j-core [tests] contains more comprehensive alternatives)
>>>>>> log4j-samples-flume-remote (flume-specific)
>>>>>> log4j-samples-flume-embedded (flume-specific)
>>>>>> log4j-samples-flume-common (flume-specific)
>>>>>> log4j-samples-configuration (contains 3 very trivial example classes,
>>>>>> log4j-core [tests] contains more comprehensive alternatives)
>>>>>>
>>>>>> I propose removing log4j-samples module and, if necessary, moving
>>>>>> Flume-related parts to the log4j-flume-ng.
>>>>>>
>>>>>> I have kept log4j-layout-template-json in the logging-log4j project,
>>>>> since
>>>>>> it has no external dependencies. This said, I am okay with moving it
>>>> to a
>>>>>> separate logging-log4j-layout project.
>>>>>>
>>>>>> Please share your remarks. Eventually, I want to translate this into a
>>>>> JIRA
>>>>>> ticket.
>>>>>>
>>>>>> Kind regards.
>>>>>>
>>>>>> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <
>>>> ralph.goers@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Gary,
>>>>>>>
>>>>>>> I am -1 to almost every item on your list.
>>>>>>>
>>>>>>> When I said break up I meant mostly moving most everything outside of
>>>>>>> log4j-core,
>>>>>>> log4j-api, and log4j-plugins into separate repos such as
>>>>>>> logging-log4j-nosql,
>>>>>>> logging-log4j-pubsub, etc. These would not require groupId or
>>>>> artifactId
>>>>>>> changes
>>>>>>> although the versioning would potentially be out of synch with the
>>>> main
>>>>>>> releases
>>>>>>> as each would be on its own release cycle. This would greatly
>>>> simplify
>>>>>>> releasing
>>>>>>> core but it would require careful though on what the versions would
>>>> be
>>>>>> for
>>>>>>> the
>>>>>>> “extra” projects.
>>>>>>>
>>>>>>> As for further breaking up core, that should revolve primarily around
>>>>>>> reducing the
>>>>>>> dependencies listed in module-info.java to the bare minimum.
>>>>>>>
>>>>>>> There will be no log4j3. We cannot change groupIds, artifactIds, or
>>>>>>> package names,
>>>>>>> other than what has been done to support JPMS. A world in which a
>>>>> log4j2
>>>>>>> and
>>>>>>> log4j3 try to co-exist would be an unmitigated disaster. Commons can
>>>>>>> happily get
>>>>>>> away with that. Log4j cannot.
>>>>>>>
>>>>>>> If an application had both log4j2 and log4j3 jars present they would
>>>>> end
>>>>>>> up with
>>>>>>> multiple LoggerContexts, multiple Configurations, and multiple
>>>> Appender
>>>>>>> Managers
>>>>>>> where today there is only a single one. That would mean two instances
>>>>> of
>>>>>>> the same
>>>>>>> configuration file would be active at once. So when it is time to
>>>>>> rollover
>>>>>>> it would
>>>>>>> be performed twice instead of once as a simple example. For this
>>>> reason
>>>>>> we
>>>>>>> CANNOT break backward compatibility.
>>>>>>>
>>>>>>> However, we are talking about runtime backward compatibility. The
>>>>> Plugin
>>>>>>> system
>>>>>>> was changed internally in 3.0 so that plugins compiled with 3.0 use
>>>>>>> ServiceLoader
>>>>>>> instead of the data file. However, it will still find and use 2.x
>>>>> plugins
>>>>>>> when they are
>>>>>>> present and can be located.
>>>>>>>
>>>>>>> The meaning of this should be clear. It is 3.0 because to take
>>>>> advantage
>>>>>>> of its
>>>>>>> features you may have to make code changes. But it will tolerate code
>>>>>> that
>>>>>>> was
>>>>>>> compiled for 2.x.
>>>>>>>
>>>>>>> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
>>>>>>> 1. Plugins must be compiled with 3.0 to use the ServiceLoader
>>>>> packaging.
>>>>>>> 2. It requires Java 11. We still need to support Java 8.
>>>>>>> 3. It fully supports JPMS. Release 2.x does not. It is likely that
>>>>>>> applications with
>>>>>>> multiple Module Layers might not be able to find all the plugins.
>>>>> Adding
>>>>>>> full JPMS
>>>>>>> support to 2.x simply isn’t possible.
>>>>>>> 4. It will be introducing new DI injection features not present in
>>>> 2.x.
>>>>>>>
>>>>>>> Major releases do not imply that you are completely breaking backward
>>>>>>> compatibility.
>>>>>>> They imply that some kind of compatibility is broken, which we are
>>>>> doing
>>>>>>> by
>>>>>>> requiring coding changes to Plugins to compile with 3.0. This means
>>>> we
>>>>>>> need to
>>>>>>> leave in any classes or methods that existing plugins might have
>>>> used.
>>>>> It
>>>>>>> means
>>>>>>> we have to continue using our own Supplier unless it can be verified
>>>>> that
>>>>>>> an
>>>>>>> application using the Supplier in 2.x can run with 3.0 even if it is
>>>>>>> converted to
>>>>>>> java.util.function.Supplier. I have no idea if the code the compiler
>>>>>>> generates
>>>>>>> for lambdas actually implements the declared interface or not.
>>>>>>>
>>>>>>> Log4j 3.0 is a major change. But that doesn’t mean we can screw our
>>>>> users
>>>>>>> by
>>>>>>> breaking everything.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> These are all IMOs of course, YMMV:
>>>>>>>> - What's the rush to 3.0?
>>>>>>>>
>>>>>>>> - I'm all for breaking up the core and other artifacts into more
>>>>>>>> artifacts based on their dependencies requirement such that
>>>> depending
>>>>>>>> on Log4j 3 does not "suck in the world", for example, I should be
>>>>> able
>>>>>>>> to depend on a currently non-existent "log4j3-console" and only
>>>> bring
>>>>>>>> in a tiny bit of code (API, a tiny core, and no plugin system). I
>>>> did
>>>>>>>> a fair amount of breaking up of various artifacts a while back.
>>>>>>>>
>>>>>>>> - 3.0 is a MAJOR release that gives us the opportunity to drop
>>>>>>>> deprecated APIs and code like our custom functional interfaces:
>>>>>>>> Supplier and so on. If we do not clean up, then there is no point
>>>> in
>>>>> a
>>>>>>>> major release. Basically, I expect to break binary and source
>>>>>>>> compatibility.
>>>>>>>>
>>>>>>>> - 3.0 must be in a new package namespace and new Maven
>>>> coordinates. I
>>>>>>>> MUST be able to run Log4j 1, 2, and 3 in the same class loader. I
>>>> can
>>>>>>>> already run Log4j 1 and 2 side by side which is good.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
>>>>> volkan.yazici@gmail.com
>>>>>>>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Ralph, count me in for such a change. I really want to have
>>>> separate
>>>>>>>>> sub-projects for such modules. This will extremely speed up
>>>>>>> build/release
>>>>>>>>> times too, which is nowadays of uttermost importance to my peace
>>>> of
>>>>>> mind
>>>>>>>>> while developing.
>>>>>>>>>
>>>>>>>>> This said, I am reluctant about such a major change when we are
>>>> this
>>>>>>> close
>>>>>>>>> to the 3.0.0 release. I guess this would definitely postpone the
>>>>> 3.0.0
>>>>>>>>> release to 2022. This will probably break the backward
>>>> compatibility
>>>>>> at
>>>>>>>>> least for the artifact groupId, am I wrong? Not to mention that
>>>> the
>>>>>>> entire
>>>>>>>>> website needs to be adapted to this multi-project setup too. Is
>>>>> there
>>>>>>>>> anything else?
>>>>>>>>>
>>>>>>>>> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
>>>>>> ralph.goers@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Yeah - I have proposed moving all these extra integrations to a
>>>>>>> separate
>>>>>>>>>> repo but
>>>>>>>>>> I’ve never gotten consensus. I’d prefer to have a project like
>>>>>>>>>> log4j-pubsub where
>>>>>>>>>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
>>>>>> nosql
>>>>>>>>>> modules, etc.
>>>>>>>>>> The problem seems to be that some people believe that we would
>>>> have
>>>>>> to
>>>>>>> cut
>>>>>>>>>> a
>>>>>>>>>> release of those every time we do a log4j release.
>>>>>>>>>>
>>>>>>>>>> If we were to do that 3.0 would be the right time.
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
>
Re: Breaking up modules into separate sub-projects
Posted by Matt Sicker <bo...@gmail.com>.
Right, a release train BOM would be its own repo basically for making
periodic dependency update releases (typically can be done around the
same time as the referenced components being released). Release trains
could either be a single log4j train or multiple trains like how
Spring has multiple projects (probably too much overhead for us?).
On Fri, 11 Jun 2021 at 10:44, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I agree with you there. Gary is correct that it would be difficult for users to
> keep track of all of this without such a mechanism. The fact is though that
> we already have it. The log4j-bom pom.xml is already included in every
> log4j release. We simply have to ensure that it always contains the correct
> versions of the artifacts.
>
> If we did this though, it might make more sense for every project to have
> its own bill of materials pom.xml and for the main log4j bom to import all of
> those instead of naming every individual artifact.
>
> If we do this I would suggest that we also consider the impact to the web
> site. I would not want to see all of these have their own web sites but
> continue to be integrated into the main web site. At the same time though,
> we would need to make it easy for users to locate the git repos for the
> components they are looking for. GitHub’s search mechanism doesn’t make
> it easy to find only the Apache logging projects, let alone just those related
> to log4j.
>
> I would also suggest that no matter what we do we will have to consider the
> impact to the web site if both release-2.x and master are being supported.
> We could imitate Tomcat and have a main web site that links to prior
> versions or we could try to modify the 3.0 web site to document what is new
> and different while keeping the doc for 2.x.
>
> I will admit though, that although Spring does this fairly successfully their
> process is a bit different than what I am imagining here. Every Spring component
> releases on its own schedule. Periodically Spring Boot and Sprint Cloud each
> have their own releases of all the components packaged together. In Log4j
> terms that would essentially mean that the log4j-bom project would be extracted
> from the main project and periodically it would be released all by itself.
>
> Ralph
>
> > On Jun 11, 2021, at 7:43 AM, Volkan Yazıcı <vo...@gmail.com> wrote:
> >
> > I definitely agree with this. This is such a convenience while using Spring.
> >
> > On Fri, Jun 11, 2021 at 4:07 PM Matt Sicker <bo...@gmail.com> wrote:
> >
> >> If we end up breaking up the modules and releasing them independently, I
> >> suggest we also adopt a release train mechanism to collect them together
> >> into single version BOM-style POM files. Also, if independent releases are
> >> faster to make and faster to verify, then we can make them more often.
> >>
> >> On Fri, Jun 11, 2021 at 05:22 Gary Gregory <ga...@gmail.com> wrote:
> >>
> >>> From my POV, this will create an incomprehensible mess of versions for
> >>> users. Big bummer.
> >>>
> >>> Gary
> >>>
> >>> On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <vo...@gmail.com>
> >> wrote:
> >>>
> >>>> To start the discussion for breaking up the modules into separate
> >>> projects,
> >>>> I propose the following structure:
> >>>>
> >>>> *logging-log4j*
> >>>> log4j-1.2-api
> >>>> log4j-api
> >>>> log4j-bom
> >>>> log4j-core
> >>>> log4j-core-its
> >>>> log4j-gctests
> >>>> log4j-iostreams
> >>>> log4j-layout-template-json
> >>>> log4j-perf
> >>>> log4j-plugins
> >>>>
> >>>> *logging-log4j-appender*
> >>>> log4j-cassandra
> >>>> log4j-couchdb
> >>>> log4j-csv
> >>>> log4j-flume-ng
> >>>> log4j-mongodb3
> >>>> log4j-mongodb4
> >>>> log4j-smtp
> >>>>
> >>>> *logging-log4j-appender-jdbc*
> >>>> log4j-jdbc (?)
> >>>> log4j-jdbc-dbcp2 (?)
> >>>> log4j-jpa
> >>>>
> >>>> *logging-log4j-appender-queue*
> >>>> log4j-jeromq
> >>>> log4j-jms
> >>>> log4j-kafka
> >>>> log4j-redis
> >>>>
> >>>> *logging-log4j-binding*
> >>>> log4j-jcl
> >>>> log4j-jpl
> >>>> log4j-jul
> >>>> log4j-liquibase
> >>>> log4j-slf4j18-impl
> >>>> log4j-slf4j-impl
> >>>> log4j-to-slf4j
> >>>>
> >>>> *logging-log4j-container*
> >>>> log4j-docker
> >>>> log4j-kubernetes
> >>>>
> >>>> *logging-log4j-gui*
> >>>> log4j-jmx-gui
> >>>>
> >>>> *logging-log4j-jee*
> >>>> log4j-appserver
> >>>> log4j-taglib
> >>>> log4j-web
> >>>>
> >>>> *logging-log4j-layout-jackson*
> >>>> log4j-layout-jackson
> >>>> log4j-layout-jackson-json
> >>>> log4j-layout-jackson-xml
> >>>> log4j-layout-jackson-yaml
> >>>>
> >>>> *logging-log4j-osgi*
> >>>> log4j-osgi
> >>>>
> >>>> *logging-log4j-spring*
> >>>> log4j-spring-boot
> >>>> log4j-spring-cloud-config
> >>>>
> >>>> Note that above breakdown contains every available module in master,
> >>> except
> >>>> log4j-samples, which has the following sub-modules:
> >>>>
> >>>> log4j-samples-loggerProperties (contains 2 very trivial example
> >> classes,
> >>>> log4j-core [tests] contains more comprehensive alternatives)
> >>>> log4j-samples-flume-remote (flume-specific)
> >>>> log4j-samples-flume-embedded (flume-specific)
> >>>> log4j-samples-flume-common (flume-specific)
> >>>> log4j-samples-configuration (contains 3 very trivial example classes,
> >>>> log4j-core [tests] contains more comprehensive alternatives)
> >>>>
> >>>> I propose removing log4j-samples module and, if necessary, moving
> >>>> Flume-related parts to the log4j-flume-ng.
> >>>>
> >>>> I have kept log4j-layout-template-json in the logging-log4j project,
> >>> since
> >>>> it has no external dependencies. This said, I am okay with moving it
> >> to a
> >>>> separate logging-log4j-layout project.
> >>>>
> >>>> Please share your remarks. Eventually, I want to translate this into a
> >>> JIRA
> >>>> ticket.
> >>>>
> >>>> Kind regards.
> >>>>
> >>>> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <
> >> ralph.goers@dslextreme.com>
> >>>> wrote:
> >>>>
> >>>>> Gary,
> >>>>>
> >>>>> I am -1 to almost every item on your list.
> >>>>>
> >>>>> When I said break up I meant mostly moving most everything outside of
> >>>>> log4j-core,
> >>>>> log4j-api, and log4j-plugins into separate repos such as
> >>>>> logging-log4j-nosql,
> >>>>> logging-log4j-pubsub, etc. These would not require groupId or
> >>> artifactId
> >>>>> changes
> >>>>> although the versioning would potentially be out of synch with the
> >> main
> >>>>> releases
> >>>>> as each would be on its own release cycle. This would greatly
> >> simplify
> >>>>> releasing
> >>>>> core but it would require careful though on what the versions would
> >> be
> >>>> for
> >>>>> the
> >>>>> “extra” projects.
> >>>>>
> >>>>> As for further breaking up core, that should revolve primarily around
> >>>>> reducing the
> >>>>> dependencies listed in module-info.java to the bare minimum.
> >>>>>
> >>>>> There will be no log4j3. We cannot change groupIds, artifactIds, or
> >>>>> package names,
> >>>>> other than what has been done to support JPMS. A world in which a
> >>> log4j2
> >>>>> and
> >>>>> log4j3 try to co-exist would be an unmitigated disaster. Commons can
> >>>>> happily get
> >>>>> away with that. Log4j cannot.
> >>>>>
> >>>>> If an application had both log4j2 and log4j3 jars present they would
> >>> end
> >>>>> up with
> >>>>> multiple LoggerContexts, multiple Configurations, and multiple
> >> Appender
> >>>>> Managers
> >>>>> where today there is only a single one. That would mean two instances
> >>> of
> >>>>> the same
> >>>>> configuration file would be active at once. So when it is time to
> >>>> rollover
> >>>>> it would
> >>>>> be performed twice instead of once as a simple example. For this
> >> reason
> >>>> we
> >>>>> CANNOT break backward compatibility.
> >>>>>
> >>>>> However, we are talking about runtime backward compatibility. The
> >>> Plugin
> >>>>> system
> >>>>> was changed internally in 3.0 so that plugins compiled with 3.0 use
> >>>>> ServiceLoader
> >>>>> instead of the data file. However, it will still find and use 2.x
> >>> plugins
> >>>>> when they are
> >>>>> present and can be located.
> >>>>>
> >>>>> The meaning of this should be clear. It is 3.0 because to take
> >>> advantage
> >>>>> of its
> >>>>> features you may have to make code changes. But it will tolerate code
> >>>> that
> >>>>> was
> >>>>> compiled for 2.x.
> >>>>>
> >>>>> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
> >>>>> 1. Plugins must be compiled with 3.0 to use the ServiceLoader
> >>> packaging.
> >>>>> 2. It requires Java 11. We still need to support Java 8.
> >>>>> 3. It fully supports JPMS. Release 2.x does not. It is likely that
> >>>>> applications with
> >>>>> multiple Module Layers might not be able to find all the plugins.
> >>> Adding
> >>>>> full JPMS
> >>>>> support to 2.x simply isn’t possible.
> >>>>> 4. It will be introducing new DI injection features not present in
> >> 2.x.
> >>>>>
> >>>>> Major releases do not imply that you are completely breaking backward
> >>>>> compatibility.
> >>>>> They imply that some kind of compatibility is broken, which we are
> >>> doing
> >>>>> by
> >>>>> requiring coding changes to Plugins to compile with 3.0. This means
> >> we
> >>>>> need to
> >>>>> leave in any classes or methods that existing plugins might have
> >> used.
> >>> It
> >>>>> means
> >>>>> we have to continue using our own Supplier unless it can be verified
> >>> that
> >>>>> an
> >>>>> application using the Supplier in 2.x can run with 3.0 even if it is
> >>>>> converted to
> >>>>> java.util.function.Supplier. I have no idea if the code the compiler
> >>>>> generates
> >>>>> for lambdas actually implements the declared interface or not.
> >>>>>
> >>>>> Log4j 3.0 is a major change. But that doesn’t mean we can screw our
> >>> users
> >>>>> by
> >>>>> breaking everything.
> >>>>>
> >>>>> Ralph
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> These are all IMOs of course, YMMV:
> >>>>>> - What's the rush to 3.0?
> >>>>>>
> >>>>>> - I'm all for breaking up the core and other artifacts into more
> >>>>>> artifacts based on their dependencies requirement such that
> >> depending
> >>>>>> on Log4j 3 does not "suck in the world", for example, I should be
> >>> able
> >>>>>> to depend on a currently non-existent "log4j3-console" and only
> >> bring
> >>>>>> in a tiny bit of code (API, a tiny core, and no plugin system). I
> >> did
> >>>>>> a fair amount of breaking up of various artifacts a while back.
> >>>>>>
> >>>>>> - 3.0 is a MAJOR release that gives us the opportunity to drop
> >>>>>> deprecated APIs and code like our custom functional interfaces:
> >>>>>> Supplier and so on. If we do not clean up, then there is no point
> >> in
> >>> a
> >>>>>> major release. Basically, I expect to break binary and source
> >>>>>> compatibility.
> >>>>>>
> >>>>>> - 3.0 must be in a new package namespace and new Maven
> >> coordinates. I
> >>>>>> MUST be able to run Log4j 1, 2, and 3 in the same class loader. I
> >> can
> >>>>>> already run Log4j 1 and 2 side by side which is good.
> >>>>>>
> >>>>>> Gary
> >>>>>>
> >>>>>> On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
> >>> volkan.yazici@gmail.com
> >>>>>
> >>>>> wrote:
> >>>>>>>
> >>>>>>> Ralph, count me in for such a change. I really want to have
> >> separate
> >>>>>>> sub-projects for such modules. This will extremely speed up
> >>>>> build/release
> >>>>>>> times too, which is nowadays of uttermost importance to my peace
> >> of
> >>>> mind
> >>>>>>> while developing.
> >>>>>>>
> >>>>>>> This said, I am reluctant about such a major change when we are
> >> this
> >>>>> close
> >>>>>>> to the 3.0.0 release. I guess this would definitely postpone the
> >>> 3.0.0
> >>>>>>> release to 2022. This will probably break the backward
> >> compatibility
> >>>> at
> >>>>>>> least for the artifact groupId, am I wrong? Not to mention that
> >> the
> >>>>> entire
> >>>>>>> website needs to be adapted to this multi-project setup too. Is
> >>> there
> >>>>>>> anything else?
> >>>>>>>
> >>>>>>> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
> >>>> ralph.goers@dslextreme.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Yeah - I have proposed moving all these extra integrations to a
> >>>>> separate
> >>>>>>>> repo but
> >>>>>>>> I’ve never gotten consensus. I’d prefer to have a project like
> >>>>>>>> log4j-pubsub where
> >>>>>>>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
> >>>> nosql
> >>>>>>>> modules, etc.
> >>>>>>>> The problem seems to be that some people believe that we would
> >> have
> >>>> to
> >>>>> cut
> >>>>>>>> a
> >>>>>>>> release of those every time we do a log4j release.
> >>>>>>>>
> >>>>>>>> If we were to do that 3.0 would be the right time.
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: Breaking up modules into separate sub-projects
Posted by Ralph Goers <ra...@dslextreme.com>.
I agree with you there. Gary is correct that it would be difficult for users to
keep track of all of this without such a mechanism. The fact is though that
we already have it. The log4j-bom pom.xml is already included in every
log4j release. We simply have to ensure that it always contains the correct
versions of the artifacts.
If we did this though, it might make more sense for every project to have
its own bill of materials pom.xml and for the main log4j bom to import all of
those instead of naming every individual artifact.
If we do this I would suggest that we also consider the impact to the web
site. I would not want to see all of these have their own web sites but
continue to be integrated into the main web site. At the same time though,
we would need to make it easy for users to locate the git repos for the
components they are looking for. GitHub’s search mechanism doesn’t make
it easy to find only the Apache logging projects, let alone just those related
to log4j.
I would also suggest that no matter what we do we will have to consider the
impact to the web site if both release-2.x and master are being supported.
We could imitate Tomcat and have a main web site that links to prior
versions or we could try to modify the 3.0 web site to document what is new
and different while keeping the doc for 2.x.
I will admit though, that although Spring does this fairly successfully their
process is a bit different than what I am imagining here. Every Spring component
releases on its own schedule. Periodically Spring Boot and Sprint Cloud each
have their own releases of all the components packaged together. In Log4j
terms that would essentially mean that the log4j-bom project would be extracted
from the main project and periodically it would be released all by itself.
Ralph
> On Jun 11, 2021, at 7:43 AM, Volkan Yazıcı <vo...@gmail.com> wrote:
>
> I definitely agree with this. This is such a convenience while using Spring.
>
> On Fri, Jun 11, 2021 at 4:07 PM Matt Sicker <bo...@gmail.com> wrote:
>
>> If we end up breaking up the modules and releasing them independently, I
>> suggest we also adopt a release train mechanism to collect them together
>> into single version BOM-style POM files. Also, if independent releases are
>> faster to make and faster to verify, then we can make them more often.
>>
>> On Fri, Jun 11, 2021 at 05:22 Gary Gregory <ga...@gmail.com> wrote:
>>
>>> From my POV, this will create an incomprehensible mess of versions for
>>> users. Big bummer.
>>>
>>> Gary
>>>
>>> On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <vo...@gmail.com>
>> wrote:
>>>
>>>> To start the discussion for breaking up the modules into separate
>>> projects,
>>>> I propose the following structure:
>>>>
>>>> *logging-log4j*
>>>> log4j-1.2-api
>>>> log4j-api
>>>> log4j-bom
>>>> log4j-core
>>>> log4j-core-its
>>>> log4j-gctests
>>>> log4j-iostreams
>>>> log4j-layout-template-json
>>>> log4j-perf
>>>> log4j-plugins
>>>>
>>>> *logging-log4j-appender*
>>>> log4j-cassandra
>>>> log4j-couchdb
>>>> log4j-csv
>>>> log4j-flume-ng
>>>> log4j-mongodb3
>>>> log4j-mongodb4
>>>> log4j-smtp
>>>>
>>>> *logging-log4j-appender-jdbc*
>>>> log4j-jdbc (?)
>>>> log4j-jdbc-dbcp2 (?)
>>>> log4j-jpa
>>>>
>>>> *logging-log4j-appender-queue*
>>>> log4j-jeromq
>>>> log4j-jms
>>>> log4j-kafka
>>>> log4j-redis
>>>>
>>>> *logging-log4j-binding*
>>>> log4j-jcl
>>>> log4j-jpl
>>>> log4j-jul
>>>> log4j-liquibase
>>>> log4j-slf4j18-impl
>>>> log4j-slf4j-impl
>>>> log4j-to-slf4j
>>>>
>>>> *logging-log4j-container*
>>>> log4j-docker
>>>> log4j-kubernetes
>>>>
>>>> *logging-log4j-gui*
>>>> log4j-jmx-gui
>>>>
>>>> *logging-log4j-jee*
>>>> log4j-appserver
>>>> log4j-taglib
>>>> log4j-web
>>>>
>>>> *logging-log4j-layout-jackson*
>>>> log4j-layout-jackson
>>>> log4j-layout-jackson-json
>>>> log4j-layout-jackson-xml
>>>> log4j-layout-jackson-yaml
>>>>
>>>> *logging-log4j-osgi*
>>>> log4j-osgi
>>>>
>>>> *logging-log4j-spring*
>>>> log4j-spring-boot
>>>> log4j-spring-cloud-config
>>>>
>>>> Note that above breakdown contains every available module in master,
>>> except
>>>> log4j-samples, which has the following sub-modules:
>>>>
>>>> log4j-samples-loggerProperties (contains 2 very trivial example
>> classes,
>>>> log4j-core [tests] contains more comprehensive alternatives)
>>>> log4j-samples-flume-remote (flume-specific)
>>>> log4j-samples-flume-embedded (flume-specific)
>>>> log4j-samples-flume-common (flume-specific)
>>>> log4j-samples-configuration (contains 3 very trivial example classes,
>>>> log4j-core [tests] contains more comprehensive alternatives)
>>>>
>>>> I propose removing log4j-samples module and, if necessary, moving
>>>> Flume-related parts to the log4j-flume-ng.
>>>>
>>>> I have kept log4j-layout-template-json in the logging-log4j project,
>>> since
>>>> it has no external dependencies. This said, I am okay with moving it
>> to a
>>>> separate logging-log4j-layout project.
>>>>
>>>> Please share your remarks. Eventually, I want to translate this into a
>>> JIRA
>>>> ticket.
>>>>
>>>> Kind regards.
>>>>
>>>> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <
>> ralph.goers@dslextreme.com>
>>>> wrote:
>>>>
>>>>> Gary,
>>>>>
>>>>> I am -1 to almost every item on your list.
>>>>>
>>>>> When I said break up I meant mostly moving most everything outside of
>>>>> log4j-core,
>>>>> log4j-api, and log4j-plugins into separate repos such as
>>>>> logging-log4j-nosql,
>>>>> logging-log4j-pubsub, etc. These would not require groupId or
>>> artifactId
>>>>> changes
>>>>> although the versioning would potentially be out of synch with the
>> main
>>>>> releases
>>>>> as each would be on its own release cycle. This would greatly
>> simplify
>>>>> releasing
>>>>> core but it would require careful though on what the versions would
>> be
>>>> for
>>>>> the
>>>>> “extra” projects.
>>>>>
>>>>> As for further breaking up core, that should revolve primarily around
>>>>> reducing the
>>>>> dependencies listed in module-info.java to the bare minimum.
>>>>>
>>>>> There will be no log4j3. We cannot change groupIds, artifactIds, or
>>>>> package names,
>>>>> other than what has been done to support JPMS. A world in which a
>>> log4j2
>>>>> and
>>>>> log4j3 try to co-exist would be an unmitigated disaster. Commons can
>>>>> happily get
>>>>> away with that. Log4j cannot.
>>>>>
>>>>> If an application had both log4j2 and log4j3 jars present they would
>>> end
>>>>> up with
>>>>> multiple LoggerContexts, multiple Configurations, and multiple
>> Appender
>>>>> Managers
>>>>> where today there is only a single one. That would mean two instances
>>> of
>>>>> the same
>>>>> configuration file would be active at once. So when it is time to
>>>> rollover
>>>>> it would
>>>>> be performed twice instead of once as a simple example. For this
>> reason
>>>> we
>>>>> CANNOT break backward compatibility.
>>>>>
>>>>> However, we are talking about runtime backward compatibility. The
>>> Plugin
>>>>> system
>>>>> was changed internally in 3.0 so that plugins compiled with 3.0 use
>>>>> ServiceLoader
>>>>> instead of the data file. However, it will still find and use 2.x
>>> plugins
>>>>> when they are
>>>>> present and can be located.
>>>>>
>>>>> The meaning of this should be clear. It is 3.0 because to take
>>> advantage
>>>>> of its
>>>>> features you may have to make code changes. But it will tolerate code
>>>> that
>>>>> was
>>>>> compiled for 2.x.
>>>>>
>>>>> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
>>>>> 1. Plugins must be compiled with 3.0 to use the ServiceLoader
>>> packaging.
>>>>> 2. It requires Java 11. We still need to support Java 8.
>>>>> 3. It fully supports JPMS. Release 2.x does not. It is likely that
>>>>> applications with
>>>>> multiple Module Layers might not be able to find all the plugins.
>>> Adding
>>>>> full JPMS
>>>>> support to 2.x simply isn’t possible.
>>>>> 4. It will be introducing new DI injection features not present in
>> 2.x.
>>>>>
>>>>> Major releases do not imply that you are completely breaking backward
>>>>> compatibility.
>>>>> They imply that some kind of compatibility is broken, which we are
>>> doing
>>>>> by
>>>>> requiring coding changes to Plugins to compile with 3.0. This means
>> we
>>>>> need to
>>>>> leave in any classes or methods that existing plugins might have
>> used.
>>> It
>>>>> means
>>>>> we have to continue using our own Supplier unless it can be verified
>>> that
>>>>> an
>>>>> application using the Supplier in 2.x can run with 3.0 even if it is
>>>>> converted to
>>>>> java.util.function.Supplier. I have no idea if the code the compiler
>>>>> generates
>>>>> for lambdas actually implements the declared interface or not.
>>>>>
>>>>> Log4j 3.0 is a major change. But that doesn’t mean we can screw our
>>> users
>>>>> by
>>>>> breaking everything.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>
>>>>>> On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> These are all IMOs of course, YMMV:
>>>>>> - What's the rush to 3.0?
>>>>>>
>>>>>> - I'm all for breaking up the core and other artifacts into more
>>>>>> artifacts based on their dependencies requirement such that
>> depending
>>>>>> on Log4j 3 does not "suck in the world", for example, I should be
>>> able
>>>>>> to depend on a currently non-existent "log4j3-console" and only
>> bring
>>>>>> in a tiny bit of code (API, a tiny core, and no plugin system). I
>> did
>>>>>> a fair amount of breaking up of various artifacts a while back.
>>>>>>
>>>>>> - 3.0 is a MAJOR release that gives us the opportunity to drop
>>>>>> deprecated APIs and code like our custom functional interfaces:
>>>>>> Supplier and so on. If we do not clean up, then there is no point
>> in
>>> a
>>>>>> major release. Basically, I expect to break binary and source
>>>>>> compatibility.
>>>>>>
>>>>>> - 3.0 must be in a new package namespace and new Maven
>> coordinates. I
>>>>>> MUST be able to run Log4j 1, 2, and 3 in the same class loader. I
>> can
>>>>>> already run Log4j 1 and 2 side by side which is good.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
>>> volkan.yazici@gmail.com
>>>>>
>>>>> wrote:
>>>>>>>
>>>>>>> Ralph, count me in for such a change. I really want to have
>> separate
>>>>>>> sub-projects for such modules. This will extremely speed up
>>>>> build/release
>>>>>>> times too, which is nowadays of uttermost importance to my peace
>> of
>>>> mind
>>>>>>> while developing.
>>>>>>>
>>>>>>> This said, I am reluctant about such a major change when we are
>> this
>>>>> close
>>>>>>> to the 3.0.0 release. I guess this would definitely postpone the
>>> 3.0.0
>>>>>>> release to 2022. This will probably break the backward
>> compatibility
>>>> at
>>>>>>> least for the artifact groupId, am I wrong? Not to mention that
>> the
>>>>> entire
>>>>>>> website needs to be adapted to this multi-project setup too. Is
>>> there
>>>>>>> anything else?
>>>>>>>
>>>>>>> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
>>>> ralph.goers@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yeah - I have proposed moving all these extra integrations to a
>>>>> separate
>>>>>>>> repo but
>>>>>>>> I’ve never gotten consensus. I’d prefer to have a project like
>>>>>>>> log4j-pubsub where
>>>>>>>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
>>>> nosql
>>>>>>>> modules, etc.
>>>>>>>> The problem seems to be that some people believe that we would
>> have
>>>> to
>>>>> cut
>>>>>>>> a
>>>>>>>> release of those every time we do a log4j release.
>>>>>>>>
>>>>>>>> If we were to do that 3.0 would be the right time.
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
Re: Breaking up modules into separate sub-projects
Posted by Volkan Yazıcı <vo...@gmail.com>.
I definitely agree with this. This is such a convenience while using Spring.
On Fri, Jun 11, 2021 at 4:07 PM Matt Sicker <bo...@gmail.com> wrote:
> If we end up breaking up the modules and releasing them independently, I
> suggest we also adopt a release train mechanism to collect them together
> into single version BOM-style POM files. Also, if independent releases are
> faster to make and faster to verify, then we can make them more often.
>
> On Fri, Jun 11, 2021 at 05:22 Gary Gregory <ga...@gmail.com> wrote:
>
> > From my POV, this will create an incomprehensible mess of versions for
> > users. Big bummer.
> >
> > Gary
> >
> > On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <vo...@gmail.com>
> wrote:
> >
> > > To start the discussion for breaking up the modules into separate
> > projects,
> > > I propose the following structure:
> > >
> > > *logging-log4j*
> > > log4j-1.2-api
> > > log4j-api
> > > log4j-bom
> > > log4j-core
> > > log4j-core-its
> > > log4j-gctests
> > > log4j-iostreams
> > > log4j-layout-template-json
> > > log4j-perf
> > > log4j-plugins
> > >
> > > *logging-log4j-appender*
> > > log4j-cassandra
> > > log4j-couchdb
> > > log4j-csv
> > > log4j-flume-ng
> > > log4j-mongodb3
> > > log4j-mongodb4
> > > log4j-smtp
> > >
> > > *logging-log4j-appender-jdbc*
> > > log4j-jdbc (?)
> > > log4j-jdbc-dbcp2 (?)
> > > log4j-jpa
> > >
> > > *logging-log4j-appender-queue*
> > > log4j-jeromq
> > > log4j-jms
> > > log4j-kafka
> > > log4j-redis
> > >
> > > *logging-log4j-binding*
> > > log4j-jcl
> > > log4j-jpl
> > > log4j-jul
> > > log4j-liquibase
> > > log4j-slf4j18-impl
> > > log4j-slf4j-impl
> > > log4j-to-slf4j
> > >
> > > *logging-log4j-container*
> > > log4j-docker
> > > log4j-kubernetes
> > >
> > > *logging-log4j-gui*
> > > log4j-jmx-gui
> > >
> > > *logging-log4j-jee*
> > > log4j-appserver
> > > log4j-taglib
> > > log4j-web
> > >
> > > *logging-log4j-layout-jackson*
> > > log4j-layout-jackson
> > > log4j-layout-jackson-json
> > > log4j-layout-jackson-xml
> > > log4j-layout-jackson-yaml
> > >
> > > *logging-log4j-osgi*
> > > log4j-osgi
> > >
> > > *logging-log4j-spring*
> > > log4j-spring-boot
> > > log4j-spring-cloud-config
> > >
> > > Note that above breakdown contains every available module in master,
> > except
> > > log4j-samples, which has the following sub-modules:
> > >
> > > log4j-samples-loggerProperties (contains 2 very trivial example
> classes,
> > > log4j-core [tests] contains more comprehensive alternatives)
> > > log4j-samples-flume-remote (flume-specific)
> > > log4j-samples-flume-embedded (flume-specific)
> > > log4j-samples-flume-common (flume-specific)
> > > log4j-samples-configuration (contains 3 very trivial example classes,
> > > log4j-core [tests] contains more comprehensive alternatives)
> > >
> > > I propose removing log4j-samples module and, if necessary, moving
> > > Flume-related parts to the log4j-flume-ng.
> > >
> > > I have kept log4j-layout-template-json in the logging-log4j project,
> > since
> > > it has no external dependencies. This said, I am okay with moving it
> to a
> > > separate logging-log4j-layout project.
> > >
> > > Please share your remarks. Eventually, I want to translate this into a
> > JIRA
> > > ticket.
> > >
> > > Kind regards.
> > >
> > > On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <
> ralph.goers@dslextreme.com>
> > > wrote:
> > >
> > > > Gary,
> > > >
> > > > I am -1 to almost every item on your list.
> > > >
> > > > When I said break up I meant mostly moving most everything outside of
> > > > log4j-core,
> > > > log4j-api, and log4j-plugins into separate repos such as
> > > > logging-log4j-nosql,
> > > > logging-log4j-pubsub, etc. These would not require groupId or
> > artifactId
> > > > changes
> > > > although the versioning would potentially be out of synch with the
> main
> > > > releases
> > > > as each would be on its own release cycle. This would greatly
> simplify
> > > > releasing
> > > > core but it would require careful though on what the versions would
> be
> > > for
> > > > the
> > > > “extra” projects.
> > > >
> > > > As for further breaking up core, that should revolve primarily around
> > > > reducing the
> > > > dependencies listed in module-info.java to the bare minimum.
> > > >
> > > > There will be no log4j3. We cannot change groupIds, artifactIds, or
> > > > package names,
> > > > other than what has been done to support JPMS. A world in which a
> > log4j2
> > > > and
> > > > log4j3 try to co-exist would be an unmitigated disaster. Commons can
> > > > happily get
> > > > away with that. Log4j cannot.
> > > >
> > > > If an application had both log4j2 and log4j3 jars present they would
> > end
> > > > up with
> > > > multiple LoggerContexts, multiple Configurations, and multiple
> Appender
> > > > Managers
> > > > where today there is only a single one. That would mean two instances
> > of
> > > > the same
> > > > configuration file would be active at once. So when it is time to
> > > rollover
> > > > it would
> > > > be performed twice instead of once as a simple example. For this
> reason
> > > we
> > > > CANNOT break backward compatibility.
> > > >
> > > > However, we are talking about runtime backward compatibility. The
> > Plugin
> > > > system
> > > > was changed internally in 3.0 so that plugins compiled with 3.0 use
> > > > ServiceLoader
> > > > instead of the data file. However, it will still find and use 2.x
> > plugins
> > > > when they are
> > > > present and can be located.
> > > >
> > > > The meaning of this should be clear. It is 3.0 because to take
> > advantage
> > > > of its
> > > > features you may have to make code changes. But it will tolerate code
> > > that
> > > > was
> > > > compiled for 2.x.
> > > >
> > > > The reasons why it is 3.0 and not a simple upgrade to 2.x are:
> > > > 1. Plugins must be compiled with 3.0 to use the ServiceLoader
> > packaging.
> > > > 2. It requires Java 11. We still need to support Java 8.
> > > > 3. It fully supports JPMS. Release 2.x does not. It is likely that
> > > > applications with
> > > > multiple Module Layers might not be able to find all the plugins.
> > Adding
> > > > full JPMS
> > > > support to 2.x simply isn’t possible.
> > > > 4. It will be introducing new DI injection features not present in
> 2.x.
> > > >
> > > > Major releases do not imply that you are completely breaking backward
> > > > compatibility.
> > > > They imply that some kind of compatibility is broken, which we are
> > doing
> > > > by
> > > > requiring coding changes to Plugins to compile with 3.0. This means
> we
> > > > need to
> > > > leave in any classes or methods that existing plugins might have
> used.
> > It
> > > > means
> > > > we have to continue using our own Supplier unless it can be verified
> > that
> > > > an
> > > > application using the Supplier in 2.x can run with 3.0 even if it is
> > > > converted to
> > > > java.util.function.Supplier. I have no idea if the code the compiler
> > > > generates
> > > > for lambdas actually implements the declared interface or not.
> > > >
> > > > Log4j 3.0 is a major change. But that doesn’t mean we can screw our
> > users
> > > > by
> > > > breaking everything.
> > > >
> > > > Ralph
> > > >
> > > >
> > > >
> > > > > On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
> > > > wrote:
> > > > >
> > > > > These are all IMOs of course, YMMV:
> > > > > - What's the rush to 3.0?
> > > > >
> > > > > - I'm all for breaking up the core and other artifacts into more
> > > > > artifacts based on their dependencies requirement such that
> depending
> > > > > on Log4j 3 does not "suck in the world", for example, I should be
> > able
> > > > > to depend on a currently non-existent "log4j3-console" and only
> bring
> > > > > in a tiny bit of code (API, a tiny core, and no plugin system). I
> did
> > > > > a fair amount of breaking up of various artifacts a while back.
> > > > >
> > > > > - 3.0 is a MAJOR release that gives us the opportunity to drop
> > > > > deprecated APIs and code like our custom functional interfaces:
> > > > > Supplier and so on. If we do not clean up, then there is no point
> in
> > a
> > > > > major release. Basically, I expect to break binary and source
> > > > > compatibility.
> > > > >
> > > > > - 3.0 must be in a new package namespace and new Maven
> coordinates. I
> > > > > MUST be able to run Log4j 1, 2, and 3 in the same class loader. I
> can
> > > > > already run Log4j 1 and 2 side by side which is good.
> > > > >
> > > > > Gary
> > > > >
> > > > > On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
> > volkan.yazici@gmail.com
> > > >
> > > > wrote:
> > > > >>
> > > > >> Ralph, count me in for such a change. I really want to have
> separate
> > > > >> sub-projects for such modules. This will extremely speed up
> > > > build/release
> > > > >> times too, which is nowadays of uttermost importance to my peace
> of
> > > mind
> > > > >> while developing.
> > > > >>
> > > > >> This said, I am reluctant about such a major change when we are
> this
> > > > close
> > > > >> to the 3.0.0 release. I guess this would definitely postpone the
> > 3.0.0
> > > > >> release to 2022. This will probably break the backward
> compatibility
> > > at
> > > > >> least for the artifact groupId, am I wrong? Not to mention that
> the
> > > > entire
> > > > >> website needs to be adapted to this multi-project setup too. Is
> > there
> > > > >> anything else?
> > > > >>
> > > > >> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
> > > ralph.goers@dslextreme.com>
> > > > >> wrote:
> > > > >>
> > > > >>> Yeah - I have proposed moving all these extra integrations to a
> > > > separate
> > > > >>> repo but
> > > > >>> I’ve never gotten consensus. I’d prefer to have a project like
> > > > >>> log4j-pubsub where
> > > > >>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
> > > nosql
> > > > >>> modules, etc.
> > > > >>> The problem seems to be that some people believe that we would
> have
> > > to
> > > > cut
> > > > >>> a
> > > > >>> release of those every time we do a log4j release.
> > > > >>>
> > > > >>> If we were to do that 3.0 would be the right time.
> > > > >>>
> > > > >
> > > >
> > > >
> > > >
> > >
> >
>
Re: Breaking up modules into separate sub-projects
Posted by Matt Sicker <bo...@gmail.com>.
If we end up breaking up the modules and releasing them independently, I
suggest we also adopt a release train mechanism to collect them together
into single version BOM-style POM files. Also, if independent releases are
faster to make and faster to verify, then we can make them more often.
On Fri, Jun 11, 2021 at 05:22 Gary Gregory <ga...@gmail.com> wrote:
> From my POV, this will create an incomprehensible mess of versions for
> users. Big bummer.
>
> Gary
>
> On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <vo...@gmail.com> wrote:
>
> > To start the discussion for breaking up the modules into separate
> projects,
> > I propose the following structure:
> >
> > *logging-log4j*
> > log4j-1.2-api
> > log4j-api
> > log4j-bom
> > log4j-core
> > log4j-core-its
> > log4j-gctests
> > log4j-iostreams
> > log4j-layout-template-json
> > log4j-perf
> > log4j-plugins
> >
> > *logging-log4j-appender*
> > log4j-cassandra
> > log4j-couchdb
> > log4j-csv
> > log4j-flume-ng
> > log4j-mongodb3
> > log4j-mongodb4
> > log4j-smtp
> >
> > *logging-log4j-appender-jdbc*
> > log4j-jdbc (?)
> > log4j-jdbc-dbcp2 (?)
> > log4j-jpa
> >
> > *logging-log4j-appender-queue*
> > log4j-jeromq
> > log4j-jms
> > log4j-kafka
> > log4j-redis
> >
> > *logging-log4j-binding*
> > log4j-jcl
> > log4j-jpl
> > log4j-jul
> > log4j-liquibase
> > log4j-slf4j18-impl
> > log4j-slf4j-impl
> > log4j-to-slf4j
> >
> > *logging-log4j-container*
> > log4j-docker
> > log4j-kubernetes
> >
> > *logging-log4j-gui*
> > log4j-jmx-gui
> >
> > *logging-log4j-jee*
> > log4j-appserver
> > log4j-taglib
> > log4j-web
> >
> > *logging-log4j-layout-jackson*
> > log4j-layout-jackson
> > log4j-layout-jackson-json
> > log4j-layout-jackson-xml
> > log4j-layout-jackson-yaml
> >
> > *logging-log4j-osgi*
> > log4j-osgi
> >
> > *logging-log4j-spring*
> > log4j-spring-boot
> > log4j-spring-cloud-config
> >
> > Note that above breakdown contains every available module in master,
> except
> > log4j-samples, which has the following sub-modules:
> >
> > log4j-samples-loggerProperties (contains 2 very trivial example classes,
> > log4j-core [tests] contains more comprehensive alternatives)
> > log4j-samples-flume-remote (flume-specific)
> > log4j-samples-flume-embedded (flume-specific)
> > log4j-samples-flume-common (flume-specific)
> > log4j-samples-configuration (contains 3 very trivial example classes,
> > log4j-core [tests] contains more comprehensive alternatives)
> >
> > I propose removing log4j-samples module and, if necessary, moving
> > Flume-related parts to the log4j-flume-ng.
> >
> > I have kept log4j-layout-template-json in the logging-log4j project,
> since
> > it has no external dependencies. This said, I am okay with moving it to a
> > separate logging-log4j-layout project.
> >
> > Please share your remarks. Eventually, I want to translate this into a
> JIRA
> > ticket.
> >
> > Kind regards.
> >
> > On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> > > Gary,
> > >
> > > I am -1 to almost every item on your list.
> > >
> > > When I said break up I meant mostly moving most everything outside of
> > > log4j-core,
> > > log4j-api, and log4j-plugins into separate repos such as
> > > logging-log4j-nosql,
> > > logging-log4j-pubsub, etc. These would not require groupId or
> artifactId
> > > changes
> > > although the versioning would potentially be out of synch with the main
> > > releases
> > > as each would be on its own release cycle. This would greatly simplify
> > > releasing
> > > core but it would require careful though on what the versions would be
> > for
> > > the
> > > “extra” projects.
> > >
> > > As for further breaking up core, that should revolve primarily around
> > > reducing the
> > > dependencies listed in module-info.java to the bare minimum.
> > >
> > > There will be no log4j3. We cannot change groupIds, artifactIds, or
> > > package names,
> > > other than what has been done to support JPMS. A world in which a
> log4j2
> > > and
> > > log4j3 try to co-exist would be an unmitigated disaster. Commons can
> > > happily get
> > > away with that. Log4j cannot.
> > >
> > > If an application had both log4j2 and log4j3 jars present they would
> end
> > > up with
> > > multiple LoggerContexts, multiple Configurations, and multiple Appender
> > > Managers
> > > where today there is only a single one. That would mean two instances
> of
> > > the same
> > > configuration file would be active at once. So when it is time to
> > rollover
> > > it would
> > > be performed twice instead of once as a simple example. For this reason
> > we
> > > CANNOT break backward compatibility.
> > >
> > > However, we are talking about runtime backward compatibility. The
> Plugin
> > > system
> > > was changed internally in 3.0 so that plugins compiled with 3.0 use
> > > ServiceLoader
> > > instead of the data file. However, it will still find and use 2.x
> plugins
> > > when they are
> > > present and can be located.
> > >
> > > The meaning of this should be clear. It is 3.0 because to take
> advantage
> > > of its
> > > features you may have to make code changes. But it will tolerate code
> > that
> > > was
> > > compiled for 2.x.
> > >
> > > The reasons why it is 3.0 and not a simple upgrade to 2.x are:
> > > 1. Plugins must be compiled with 3.0 to use the ServiceLoader
> packaging.
> > > 2. It requires Java 11. We still need to support Java 8.
> > > 3. It fully supports JPMS. Release 2.x does not. It is likely that
> > > applications with
> > > multiple Module Layers might not be able to find all the plugins.
> Adding
> > > full JPMS
> > > support to 2.x simply isn’t possible.
> > > 4. It will be introducing new DI injection features not present in 2.x.
> > >
> > > Major releases do not imply that you are completely breaking backward
> > > compatibility.
> > > They imply that some kind of compatibility is broken, which we are
> doing
> > > by
> > > requiring coding changes to Plugins to compile with 3.0. This means we
> > > need to
> > > leave in any classes or methods that existing plugins might have used.
> It
> > > means
> > > we have to continue using our own Supplier unless it can be verified
> that
> > > an
> > > application using the Supplier in 2.x can run with 3.0 even if it is
> > > converted to
> > > java.util.function.Supplier. I have no idea if the code the compiler
> > > generates
> > > for lambdas actually implements the declared interface or not.
> > >
> > > Log4j 3.0 is a major change. But that doesn’t mean we can screw our
> users
> > > by
> > > breaking everything.
> > >
> > > Ralph
> > >
> > >
> > >
> > > > On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
> > > wrote:
> > > >
> > > > These are all IMOs of course, YMMV:
> > > > - What's the rush to 3.0?
> > > >
> > > > - I'm all for breaking up the core and other artifacts into more
> > > > artifacts based on their dependencies requirement such that depending
> > > > on Log4j 3 does not "suck in the world", for example, I should be
> able
> > > > to depend on a currently non-existent "log4j3-console" and only bring
> > > > in a tiny bit of code (API, a tiny core, and no plugin system). I did
> > > > a fair amount of breaking up of various artifacts a while back.
> > > >
> > > > - 3.0 is a MAJOR release that gives us the opportunity to drop
> > > > deprecated APIs and code like our custom functional interfaces:
> > > > Supplier and so on. If we do not clean up, then there is no point in
> a
> > > > major release. Basically, I expect to break binary and source
> > > > compatibility.
> > > >
> > > > - 3.0 must be in a new package namespace and new Maven coordinates. I
> > > > MUST be able to run Log4j 1, 2, and 3 in the same class loader. I can
> > > > already run Log4j 1 and 2 side by side which is good.
> > > >
> > > > Gary
> > > >
> > > > On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
> volkan.yazici@gmail.com
> > >
> > > wrote:
> > > >>
> > > >> Ralph, count me in for such a change. I really want to have separate
> > > >> sub-projects for such modules. This will extremely speed up
> > > build/release
> > > >> times too, which is nowadays of uttermost importance to my peace of
> > mind
> > > >> while developing.
> > > >>
> > > >> This said, I am reluctant about such a major change when we are this
> > > close
> > > >> to the 3.0.0 release. I guess this would definitely postpone the
> 3.0.0
> > > >> release to 2022. This will probably break the backward compatibility
> > at
> > > >> least for the artifact groupId, am I wrong? Not to mention that the
> > > entire
> > > >> website needs to be adapted to this multi-project setup too. Is
> there
> > > >> anything else?
> > > >>
> > > >> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
> > ralph.goers@dslextreme.com>
> > > >> wrote:
> > > >>
> > > >>> Yeah - I have proposed moving all these extra integrations to a
> > > separate
> > > >>> repo but
> > > >>> I’ve never gotten consensus. I’d prefer to have a project like
> > > >>> log4j-pubsub where
> > > >>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
> > nosql
> > > >>> modules, etc.
> > > >>> The problem seems to be that some people believe that we would have
> > to
> > > cut
> > > >>> a
> > > >>> release of those every time we do a log4j release.
> > > >>>
> > > >>> If we were to do that 3.0 would be the right time.
> > > >>>
> > > >
> > >
> > >
> > >
> >
>
Re: Breaking up modules into separate sub-projects
Posted by Gary Gregory <ga...@gmail.com>.
From my POV, this will create an incomprehensible mess of versions for
users. Big bummer.
Gary
On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <vo...@gmail.com> wrote:
> To start the discussion for breaking up the modules into separate projects,
> I propose the following structure:
>
> *logging-log4j*
> log4j-1.2-api
> log4j-api
> log4j-bom
> log4j-core
> log4j-core-its
> log4j-gctests
> log4j-iostreams
> log4j-layout-template-json
> log4j-perf
> log4j-plugins
>
> *logging-log4j-appender*
> log4j-cassandra
> log4j-couchdb
> log4j-csv
> log4j-flume-ng
> log4j-mongodb3
> log4j-mongodb4
> log4j-smtp
>
> *logging-log4j-appender-jdbc*
> log4j-jdbc (?)
> log4j-jdbc-dbcp2 (?)
> log4j-jpa
>
> *logging-log4j-appender-queue*
> log4j-jeromq
> log4j-jms
> log4j-kafka
> log4j-redis
>
> *logging-log4j-binding*
> log4j-jcl
> log4j-jpl
> log4j-jul
> log4j-liquibase
> log4j-slf4j18-impl
> log4j-slf4j-impl
> log4j-to-slf4j
>
> *logging-log4j-container*
> log4j-docker
> log4j-kubernetes
>
> *logging-log4j-gui*
> log4j-jmx-gui
>
> *logging-log4j-jee*
> log4j-appserver
> log4j-taglib
> log4j-web
>
> *logging-log4j-layout-jackson*
> log4j-layout-jackson
> log4j-layout-jackson-json
> log4j-layout-jackson-xml
> log4j-layout-jackson-yaml
>
> *logging-log4j-osgi*
> log4j-osgi
>
> *logging-log4j-spring*
> log4j-spring-boot
> log4j-spring-cloud-config
>
> Note that above breakdown contains every available module in master, except
> log4j-samples, which has the following sub-modules:
>
> log4j-samples-loggerProperties (contains 2 very trivial example classes,
> log4j-core [tests] contains more comprehensive alternatives)
> log4j-samples-flume-remote (flume-specific)
> log4j-samples-flume-embedded (flume-specific)
> log4j-samples-flume-common (flume-specific)
> log4j-samples-configuration (contains 3 very trivial example classes,
> log4j-core [tests] contains more comprehensive alternatives)
>
> I propose removing log4j-samples module and, if necessary, moving
> Flume-related parts to the log4j-flume-ng.
>
> I have kept log4j-layout-template-json in the logging-log4j project, since
> it has no external dependencies. This said, I am okay with moving it to a
> separate logging-log4j-layout project.
>
> Please share your remarks. Eventually, I want to translate this into a JIRA
> ticket.
>
> Kind regards.
>
> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> > Gary,
> >
> > I am -1 to almost every item on your list.
> >
> > When I said break up I meant mostly moving most everything outside of
> > log4j-core,
> > log4j-api, and log4j-plugins into separate repos such as
> > logging-log4j-nosql,
> > logging-log4j-pubsub, etc. These would not require groupId or artifactId
> > changes
> > although the versioning would potentially be out of synch with the main
> > releases
> > as each would be on its own release cycle. This would greatly simplify
> > releasing
> > core but it would require careful though on what the versions would be
> for
> > the
> > “extra” projects.
> >
> > As for further breaking up core, that should revolve primarily around
> > reducing the
> > dependencies listed in module-info.java to the bare minimum.
> >
> > There will be no log4j3. We cannot change groupIds, artifactIds, or
> > package names,
> > other than what has been done to support JPMS. A world in which a log4j2
> > and
> > log4j3 try to co-exist would be an unmitigated disaster. Commons can
> > happily get
> > away with that. Log4j cannot.
> >
> > If an application had both log4j2 and log4j3 jars present they would end
> > up with
> > multiple LoggerContexts, multiple Configurations, and multiple Appender
> > Managers
> > where today there is only a single one. That would mean two instances of
> > the same
> > configuration file would be active at once. So when it is time to
> rollover
> > it would
> > be performed twice instead of once as a simple example. For this reason
> we
> > CANNOT break backward compatibility.
> >
> > However, we are talking about runtime backward compatibility. The Plugin
> > system
> > was changed internally in 3.0 so that plugins compiled with 3.0 use
> > ServiceLoader
> > instead of the data file. However, it will still find and use 2.x plugins
> > when they are
> > present and can be located.
> >
> > The meaning of this should be clear. It is 3.0 because to take advantage
> > of its
> > features you may have to make code changes. But it will tolerate code
> that
> > was
> > compiled for 2.x.
> >
> > The reasons why it is 3.0 and not a simple upgrade to 2.x are:
> > 1. Plugins must be compiled with 3.0 to use the ServiceLoader packaging.
> > 2. It requires Java 11. We still need to support Java 8.
> > 3. It fully supports JPMS. Release 2.x does not. It is likely that
> > applications with
> > multiple Module Layers might not be able to find all the plugins. Adding
> > full JPMS
> > support to 2.x simply isn’t possible.
> > 4. It will be introducing new DI injection features not present in 2.x.
> >
> > Major releases do not imply that you are completely breaking backward
> > compatibility.
> > They imply that some kind of compatibility is broken, which we are doing
> > by
> > requiring coding changes to Plugins to compile with 3.0. This means we
> > need to
> > leave in any classes or methods that existing plugins might have used. It
> > means
> > we have to continue using our own Supplier unless it can be verified that
> > an
> > application using the Supplier in 2.x can run with 3.0 even if it is
> > converted to
> > java.util.function.Supplier. I have no idea if the code the compiler
> > generates
> > for lambdas actually implements the declared interface or not.
> >
> > Log4j 3.0 is a major change. But that doesn’t mean we can screw our users
> > by
> > breaking everything.
> >
> > Ralph
> >
> >
> >
> > > On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
> > wrote:
> > >
> > > These are all IMOs of course, YMMV:
> > > - What's the rush to 3.0?
> > >
> > > - I'm all for breaking up the core and other artifacts into more
> > > artifacts based on their dependencies requirement such that depending
> > > on Log4j 3 does not "suck in the world", for example, I should be able
> > > to depend on a currently non-existent "log4j3-console" and only bring
> > > in a tiny bit of code (API, a tiny core, and no plugin system). I did
> > > a fair amount of breaking up of various artifacts a while back.
> > >
> > > - 3.0 is a MAJOR release that gives us the opportunity to drop
> > > deprecated APIs and code like our custom functional interfaces:
> > > Supplier and so on. If we do not clean up, then there is no point in a
> > > major release. Basically, I expect to break binary and source
> > > compatibility.
> > >
> > > - 3.0 must be in a new package namespace and new Maven coordinates. I
> > > MUST be able to run Log4j 1, 2, and 3 in the same class loader. I can
> > > already run Log4j 1 and 2 side by side which is good.
> > >
> > > Gary
> > >
> > > On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <volkan.yazici@gmail.com
> >
> > wrote:
> > >>
> > >> Ralph, count me in for such a change. I really want to have separate
> > >> sub-projects for such modules. This will extremely speed up
> > build/release
> > >> times too, which is nowadays of uttermost importance to my peace of
> mind
> > >> while developing.
> > >>
> > >> This said, I am reluctant about such a major change when we are this
> > close
> > >> to the 3.0.0 release. I guess this would definitely postpone the 3.0.0
> > >> release to 2022. This will probably break the backward compatibility
> at
> > >> least for the artifact groupId, am I wrong? Not to mention that the
> > entire
> > >> website needs to be adapted to this multi-project setup too. Is there
> > >> anything else?
> > >>
> > >> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
> ralph.goers@dslextreme.com>
> > >> wrote:
> > >>
> > >>> Yeah - I have proposed moving all these extra integrations to a
> > separate
> > >>> repo but
> > >>> I’ve never gotten consensus. I’d prefer to have a project like
> > >>> log4j-pubsub where
> > >>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
> nosql
> > >>> modules, etc.
> > >>> The problem seems to be that some people believe that we would have
> to
> > cut
> > >>> a
> > >>> release of those every time we do a log4j release.
> > >>>
> > >>> If we were to do that 3.0 would be the right time.
> > >>>
> > >
> >
> >
> >
>
Re: Breaking up modules into separate sub-projects
Posted by Ralph Goers <ra...@dslextreme.com>.
Regarding Jenkins vs GitHub Actions - while the code coverage is obviously the
ame because they are both running the same build, the two systems don’t necessarily
use the same OSes and/or versions.
Ralph
> On Jun 13, 2021, at 12:32 PM, Volkan Yazıcı <vo...@gmail.com> wrote:
>
> Migrating to a Bazel-like build system will necessitate quite some effort.
> After all, they are in essence *"make in steroids"*, which translates to
> humongous manual scripting that is already there in Maven. IDE
> compatibility is another issue too. (This said, "master" in its current
> form doesn't compile in IntelliJ IDEA, ironically.) Even though having a
> single repository with blazing fast (and reproducible!) builds sounds
> charming, I don't know of such a Bazel ninja among us to turn this into
> reality. To be honest, I had sneakily investigated this option in depth
> months ago. Compilation unit granularity is a big issue there. In
> particular, I have found the presentation of Wix where they explain how
> they have migrated their builds from Maven/Gradle to Bazel
> <https://youtu.be/2UOFm-Cc_cU> pretty interesting. Long story short, I
> cannot see this plan flying and hence, agreeing with Ralph on sticking to
> Maven.
>
> Jira tickets would help us to associate the commits with tickets for
> keeping track of what and why something has changed. For administrative
> purposes, in short.
>
> I agree with your remarks about the website.
>
> Ralph, what do you mean by *"I like having both [Jenkins and GitHub
> Actions] simply because we can get more coverage"*? In theory, their
> coverages are identical. In my experience, having two separate CI pipelines
> adds nothing but confusion and maintenance burden.
>
> On Sat, Jun 12, 2021 at 1:57 AM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> No, and to be honest I am not particularly interested in moving away from
>> Maven,
>> despite its limitations.
>>
>> I am not sure what we would need Jira tickets for. Creating new GitHub
>> repos
>> is self service I believe. The web site work is going to be a bunch of
>> manual
>> effort to get the site the way we want it. We also still have to agree on
>> how
>> we want it to support both 2.x and 3.x.
>>
>> My suggestion for the web site would be to have a main site that applies
>> to
>> both and then have it link to version specific information. I would
>> suggest that
>> the main log4j web site should be pulled out of the log4j build and move
>> into
>> logging-log4j-site directly. I would think that pretty much the only stuff
>> that
>> would remain in the version specific sites would be the stuff generated by
>> the
>> maven site plugin.
>>
>> Gary, we already have GitHub Actions set up for Log4j. We also have
>> Jenkins
>> jobs. I like having both simply because we can get more coverage.
>>
>> Ralph
>>
>>
>>
>>> On Jun 11, 2021, at 2:38 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> Bazel could be interesting, but does anyone here know how to configure
>> it?
>>>
>>> On Fri, 11 Jun 2021 at 15:00, Volkan Yazıcı <vo...@gmail.com>
>> wrote:
>>>>
>>>> Since all of us are on board with the idea – except Gary, whom I will
>>>> address below – shall we work out the structuring? I already shared my
>>>> proposal. What is your preference? Once we agree on that, I can create
>>>> relevant Jira tickets, also for the website & manual updates. I can take
>>>> the responsibility of executing the plan.
>>>>
>>>> Gary, I agree with your concerns regarding the build tool. Right now
>> there
>>>> are ~50 modules in the master. As long as we execute each module's tests
>>>> sequentially, which is inevitable in Maven and Gradle, I don't think we
>> can
>>>> shave that down to 10 minutes or so. Not to mention the compile time
>>>> itself. Unless we migrate to something substantially fine-grained (e.g.,
>>>> Bazel), I can't think of this happening with Maven or Gradle. Migrating
>> to
>>>> such exotic solutions have their own trade-offs too.
>>>>
>>>> On Fri, Jun 11, 2021 at 10:29 AM Volkan Yazıcı <volkan.yazici@gmail.com
>>>
>>>> wrote:
>>>>
>>>>> To start the discussion for breaking up the modules into separate
>>>>> projects, I propose the following structure:
>>>>>
>>>>> *logging-log4j*
>>>>> log4j-1.2-api
>>>>> log4j-api
>>>>> log4j-bom
>>>>> log4j-core
>>>>> log4j-core-its
>>>>> log4j-gctests
>>>>> log4j-iostreams
>>>>> log4j-layout-template-json
>>>>> log4j-perf
>>>>> log4j-plugins
>>>>>
>>>>> *logging-log4j-appender*
>>>>> log4j-cassandra
>>>>> log4j-couchdb
>>>>> log4j-csv
>>>>> log4j-flume-ng
>>>>> log4j-mongodb3
>>>>> log4j-mongodb4
>>>>> log4j-smtp
>>>>>
>>>>> *logging-log4j-appender-jdbc*
>>>>> log4j-jdbc (?)
>>>>> log4j-jdbc-dbcp2 (?)
>>>>> log4j-jpa
>>>>>
>>>>> *logging-log4j-appender-queue*
>>>>> log4j-jeromq
>>>>> log4j-jms
>>>>> log4j-kafka
>>>>> log4j-redis
>>>>>
>>>>> *logging-log4j-binding*
>>>>> log4j-jcl
>>>>> log4j-jpl
>>>>> log4j-jul
>>>>> log4j-liquibase
>>>>> log4j-slf4j18-impl
>>>>> log4j-slf4j-impl
>>>>> log4j-to-slf4j
>>>>>
>>>>> *logging-log4j-container*
>>>>> log4j-docker
>>>>> log4j-kubernetes
>>>>>
>>>>> *logging-log4j-gui*
>>>>> log4j-jmx-gui
>>>>>
>>>>> *logging-log4j-jee*
>>>>> log4j-appserver
>>>>> log4j-taglib
>>>>> log4j-web
>>>>>
>>>>> *logging-log4j-layout-jackson*
>>>>> log4j-layout-jackson
>>>>> log4j-layout-jackson-json
>>>>> log4j-layout-jackson-xml
>>>>> log4j-layout-jackson-yaml
>>>>>
>>>>> *logging-log4j-osgi*
>>>>> log4j-osgi
>>>>>
>>>>> *logging-log4j-spring*
>>>>> log4j-spring-boot
>>>>> log4j-spring-cloud-config
>>>>>
>>>>> Note that above breakdown contains every available module in master,
>>>>> except log4j-samples, which has the following sub-modules:
>>>>>
>>>>> log4j-samples-loggerProperties (contains 2 very trivial example
>> classes,
>>>>> log4j-core [tests] contains more comprehensive alternatives)
>>>>> log4j-samples-flume-remote (flume-specific)
>>>>> log4j-samples-flume-embedded (flume-specific)
>>>>> log4j-samples-flume-common (flume-specific)
>>>>> log4j-samples-configuration (contains 3 very trivial example classes,
>>>>> log4j-core [tests] contains more comprehensive alternatives)
>>>>>
>>>>> I propose removing log4j-samples module and, if necessary, moving
>>>>> Flume-related parts to the log4j-flume-ng.
>>>>>
>>>>> I have kept log4j-layout-template-json in the logging-log4j project,
>> since
>>>>> it has no external dependencies. This said, I am okay with moving it
>> to a
>>>>> separate logging-log4j-layout project.
>>>>>
>>>>> Please share your remarks. Eventually, I want to translate this into a
>>>>> JIRA ticket.
>>>>>
>>>>> Kind regards.
>>>>>
>>>>> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <
>> ralph.goers@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> Gary,
>>>>>>
>>>>>> I am -1 to almost every item on your list.
>>>>>>
>>>>>> When I said break up I meant mostly moving most everything outside of
>>>>>> log4j-core,
>>>>>> log4j-api, and log4j-plugins into separate repos such as
>>>>>> logging-log4j-nosql,
>>>>>> logging-log4j-pubsub, etc. These would not require groupId or
>> artifactId
>>>>>> changes
>>>>>> although the versioning would potentially be out of synch with the
>> main
>>>>>> releases
>>>>>> as each would be on its own release cycle. This would greatly simplify
>>>>>> releasing
>>>>>> core but it would require careful though on what the versions would be
>>>>>> for the
>>>>>> “extra” projects.
>>>>>>
>>>>>> As for further breaking up core, that should revolve primarily around
>>>>>> reducing the
>>>>>> dependencies listed in module-info.java to the bare minimum.
>>>>>>
>>>>>> There will be no log4j3. We cannot change groupIds, artifactIds, or
>>>>>> package names,
>>>>>> other than what has been done to support JPMS. A world in which a
>> log4j2
>>>>>> and
>>>>>> log4j3 try to co-exist would be an unmitigated disaster. Commons can
>>>>>> happily get
>>>>>> away with that. Log4j cannot.
>>>>>>
>>>>>> If an application had both log4j2 and log4j3 jars present they would
>> end
>>>>>> up with
>>>>>> multiple LoggerContexts, multiple Configurations, and multiple
>> Appender
>>>>>> Managers
>>>>>> where today there is only a single one. That would mean two instances
>> of
>>>>>> the same
>>>>>> configuration file would be active at once. So when it is time to
>>>>>> rollover it would
>>>>>> be performed twice instead of once as a simple example. For this
>> reason
>>>>>> we
>>>>>> CANNOT break backward compatibility.
>>>>>>
>>>>>> However, we are talking about runtime backward compatibility. The
>> Plugin
>>>>>> system
>>>>>> was changed internally in 3.0 so that plugins compiled with 3.0 use
>>>>>> ServiceLoader
>>>>>> instead of the data file. However, it will still find and use 2.x
>> plugins
>>>>>> when they are
>>>>>> present and can be located.
>>>>>>
>>>>>> The meaning of this should be clear. It is 3.0 because to take
>> advantage
>>>>>> of its
>>>>>> features you may have to make code changes. But it will tolerate code
>>>>>> that was
>>>>>> compiled for 2.x.
>>>>>>
>>>>>> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
>>>>>> 1. Plugins must be compiled with 3.0 to use the ServiceLoader
>> packaging.
>>>>>> 2. It requires Java 11. We still need to support Java 8.
>>>>>> 3. It fully supports JPMS. Release 2.x does not. It is likely that
>>>>>> applications with
>>>>>> multiple Module Layers might not be able to find all the plugins.
>> Adding
>>>>>> full JPMS
>>>>>> support to 2.x simply isn’t possible.
>>>>>> 4. It will be introducing new DI injection features not present in
>> 2.x.
>>>>>>
>>>>>> Major releases do not imply that you are completely breaking backward
>>>>>> compatibility.
>>>>>> They imply that some kind of compatibility is broken, which we are
>> doing
>>>>>> by
>>>>>> requiring coding changes to Plugins to compile with 3.0. This means we
>>>>>> need to
>>>>>> leave in any classes or methods that existing plugins might have
>> used. It
>>>>>> means
>>>>>> we have to continue using our own Supplier unless it can be verified
>> that
>>>>>> an
>>>>>> application using the Supplier in 2.x can run with 3.0 even if it is
>>>>>> converted to
>>>>>> java.util.function.Supplier. I have no idea if the code the compiler
>>>>>> generates
>>>>>> for lambdas actually implements the declared interface or not.
>>>>>>
>>>>>> Log4j 3.0 is a major change. But that doesn’t mean we can screw our
>> users
>>>>>> by
>>>>>> breaking everything.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> These are all IMOs of course, YMMV:
>>>>>>> - What's the rush to 3.0?
>>>>>>>
>>>>>>> - I'm all for breaking up the core and other artifacts into more
>>>>>>> artifacts based on their dependencies requirement such that depending
>>>>>>> on Log4j 3 does not "suck in the world", for example, I should be
>> able
>>>>>>> to depend on a currently non-existent "log4j3-console" and only bring
>>>>>>> in a tiny bit of code (API, a tiny core, and no plugin system). I did
>>>>>>> a fair amount of breaking up of various artifacts a while back.
>>>>>>>
>>>>>>> - 3.0 is a MAJOR release that gives us the opportunity to drop
>>>>>>> deprecated APIs and code like our custom functional interfaces:
>>>>>>> Supplier and so on. If we do not clean up, then there is no point in
>> a
>>>>>>> major release. Basically, I expect to break binary and source
>>>>>>> compatibility.
>>>>>>>
>>>>>>> - 3.0 must be in a new package namespace and new Maven coordinates. I
>>>>>>> MUST be able to run Log4j 1, 2, and 3 in the same class loader. I can
>>>>>>> already run Log4j 1 and 2 side by side which is good.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
>> volkan.yazici@gmail.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> Ralph, count me in for such a change. I really want to have separate
>>>>>>>> sub-projects for such modules. This will extremely speed up
>>>>>> build/release
>>>>>>>> times too, which is nowadays of uttermost importance to my peace of
>>>>>> mind
>>>>>>>> while developing.
>>>>>>>>
>>>>>>>> This said, I am reluctant about such a major change when we are this
>>>>>> close
>>>>>>>> to the 3.0.0 release. I guess this would definitely postpone the
>> 3.0.0
>>>>>>>> release to 2022. This will probably break the backward
>> compatibility at
>>>>>>>> least for the artifact groupId, am I wrong? Not to mention that the
>>>>>> entire
>>>>>>>> website needs to be adapted to this multi-project setup too. Is
>> there
>>>>>>>> anything else?
>>>>>>>>
>>>>>>>> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
>> ralph.goers@dslextreme.com
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Yeah - I have proposed moving all these extra integrations to a
>>>>>> separate
>>>>>>>>> repo but
>>>>>>>>> I’ve never gotten consensus. I’d prefer to have a project like
>>>>>>>>> log4j-pubsub where
>>>>>>>>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
>>>>>> nosql
>>>>>>>>> modules, etc.
>>>>>>>>> The problem seems to be that some people believe that we would have
>>>>>> to cut
>>>>>>>>> a
>>>>>>>>> release of those every time we do a log4j release.
>>>>>>>>>
>>>>>>>>> If we were to do that 3.0 would be the right time.
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>
>>
>>
Re: Breaking up modules into separate sub-projects
Posted by Volkan Yazıcı <vo...@gmail.com>.
Migrating to a Bazel-like build system will necessitate quite some effort.
After all, they are in essence *"make in steroids"*, which translates to
humongous manual scripting that is already there in Maven. IDE
compatibility is another issue too. (This said, "master" in its current
form doesn't compile in IntelliJ IDEA, ironically.) Even though having a
single repository with blazing fast (and reproducible!) builds sounds
charming, I don't know of such a Bazel ninja among us to turn this into
reality. To be honest, I had sneakily investigated this option in depth
months ago. Compilation unit granularity is a big issue there. In
particular, I have found the presentation of Wix where they explain how
they have migrated their builds from Maven/Gradle to Bazel
<https://youtu.be/2UOFm-Cc_cU> pretty interesting. Long story short, I
cannot see this plan flying and hence, agreeing with Ralph on sticking to
Maven.
Jira tickets would help us to associate the commits with tickets for
keeping track of what and why something has changed. For administrative
purposes, in short.
I agree with your remarks about the website.
Ralph, what do you mean by *"I like having both [Jenkins and GitHub
Actions] simply because we can get more coverage"*? In theory, their
coverages are identical. In my experience, having two separate CI pipelines
adds nothing but confusion and maintenance burden.
On Sat, Jun 12, 2021 at 1:57 AM Ralph Goers <ra...@dslextreme.com>
wrote:
> No, and to be honest I am not particularly interested in moving away from
> Maven,
> despite its limitations.
>
> I am not sure what we would need Jira tickets for. Creating new GitHub
> repos
> is self service I believe. The web site work is going to be a bunch of
> manual
> effort to get the site the way we want it. We also still have to agree on
> how
> we want it to support both 2.x and 3.x.
>
> My suggestion for the web site would be to have a main site that applies
> to
> both and then have it link to version specific information. I would
> suggest that
> the main log4j web site should be pulled out of the log4j build and move
> into
> logging-log4j-site directly. I would think that pretty much the only stuff
> that
> would remain in the version specific sites would be the stuff generated by
> the
> maven site plugin.
>
> Gary, we already have GitHub Actions set up for Log4j. We also have
> Jenkins
> jobs. I like having both simply because we can get more coverage.
>
> Ralph
>
>
>
> > On Jun 11, 2021, at 2:38 PM, Matt Sicker <bo...@gmail.com> wrote:
> >
> > Bazel could be interesting, but does anyone here know how to configure
> it?
> >
> > On Fri, 11 Jun 2021 at 15:00, Volkan Yazıcı <vo...@gmail.com>
> wrote:
> >>
> >> Since all of us are on board with the idea – except Gary, whom I will
> >> address below – shall we work out the structuring? I already shared my
> >> proposal. What is your preference? Once we agree on that, I can create
> >> relevant Jira tickets, also for the website & manual updates. I can take
> >> the responsibility of executing the plan.
> >>
> >> Gary, I agree with your concerns regarding the build tool. Right now
> there
> >> are ~50 modules in the master. As long as we execute each module's tests
> >> sequentially, which is inevitable in Maven and Gradle, I don't think we
> can
> >> shave that down to 10 minutes or so. Not to mention the compile time
> >> itself. Unless we migrate to something substantially fine-grained (e.g.,
> >> Bazel), I can't think of this happening with Maven or Gradle. Migrating
> to
> >> such exotic solutions have their own trade-offs too.
> >>
> >> On Fri, Jun 11, 2021 at 10:29 AM Volkan Yazıcı <volkan.yazici@gmail.com
> >
> >> wrote:
> >>
> >>> To start the discussion for breaking up the modules into separate
> >>> projects, I propose the following structure:
> >>>
> >>> *logging-log4j*
> >>> log4j-1.2-api
> >>> log4j-api
> >>> log4j-bom
> >>> log4j-core
> >>> log4j-core-its
> >>> log4j-gctests
> >>> log4j-iostreams
> >>> log4j-layout-template-json
> >>> log4j-perf
> >>> log4j-plugins
> >>>
> >>> *logging-log4j-appender*
> >>> log4j-cassandra
> >>> log4j-couchdb
> >>> log4j-csv
> >>> log4j-flume-ng
> >>> log4j-mongodb3
> >>> log4j-mongodb4
> >>> log4j-smtp
> >>>
> >>> *logging-log4j-appender-jdbc*
> >>> log4j-jdbc (?)
> >>> log4j-jdbc-dbcp2 (?)
> >>> log4j-jpa
> >>>
> >>> *logging-log4j-appender-queue*
> >>> log4j-jeromq
> >>> log4j-jms
> >>> log4j-kafka
> >>> log4j-redis
> >>>
> >>> *logging-log4j-binding*
> >>> log4j-jcl
> >>> log4j-jpl
> >>> log4j-jul
> >>> log4j-liquibase
> >>> log4j-slf4j18-impl
> >>> log4j-slf4j-impl
> >>> log4j-to-slf4j
> >>>
> >>> *logging-log4j-container*
> >>> log4j-docker
> >>> log4j-kubernetes
> >>>
> >>> *logging-log4j-gui*
> >>> log4j-jmx-gui
> >>>
> >>> *logging-log4j-jee*
> >>> log4j-appserver
> >>> log4j-taglib
> >>> log4j-web
> >>>
> >>> *logging-log4j-layout-jackson*
> >>> log4j-layout-jackson
> >>> log4j-layout-jackson-json
> >>> log4j-layout-jackson-xml
> >>> log4j-layout-jackson-yaml
> >>>
> >>> *logging-log4j-osgi*
> >>> log4j-osgi
> >>>
> >>> *logging-log4j-spring*
> >>> log4j-spring-boot
> >>> log4j-spring-cloud-config
> >>>
> >>> Note that above breakdown contains every available module in master,
> >>> except log4j-samples, which has the following sub-modules:
> >>>
> >>> log4j-samples-loggerProperties (contains 2 very trivial example
> classes,
> >>> log4j-core [tests] contains more comprehensive alternatives)
> >>> log4j-samples-flume-remote (flume-specific)
> >>> log4j-samples-flume-embedded (flume-specific)
> >>> log4j-samples-flume-common (flume-specific)
> >>> log4j-samples-configuration (contains 3 very trivial example classes,
> >>> log4j-core [tests] contains more comprehensive alternatives)
> >>>
> >>> I propose removing log4j-samples module and, if necessary, moving
> >>> Flume-related parts to the log4j-flume-ng.
> >>>
> >>> I have kept log4j-layout-template-json in the logging-log4j project,
> since
> >>> it has no external dependencies. This said, I am okay with moving it
> to a
> >>> separate logging-log4j-layout project.
> >>>
> >>> Please share your remarks. Eventually, I want to translate this into a
> >>> JIRA ticket.
> >>>
> >>> Kind regards.
> >>>
> >>> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <
> ralph.goers@dslextreme.com>
> >>> wrote:
> >>>
> >>>> Gary,
> >>>>
> >>>> I am -1 to almost every item on your list.
> >>>>
> >>>> When I said break up I meant mostly moving most everything outside of
> >>>> log4j-core,
> >>>> log4j-api, and log4j-plugins into separate repos such as
> >>>> logging-log4j-nosql,
> >>>> logging-log4j-pubsub, etc. These would not require groupId or
> artifactId
> >>>> changes
> >>>> although the versioning would potentially be out of synch with the
> main
> >>>> releases
> >>>> as each would be on its own release cycle. This would greatly simplify
> >>>> releasing
> >>>> core but it would require careful though on what the versions would be
> >>>> for the
> >>>> “extra” projects.
> >>>>
> >>>> As for further breaking up core, that should revolve primarily around
> >>>> reducing the
> >>>> dependencies listed in module-info.java to the bare minimum.
> >>>>
> >>>> There will be no log4j3. We cannot change groupIds, artifactIds, or
> >>>> package names,
> >>>> other than what has been done to support JPMS. A world in which a
> log4j2
> >>>> and
> >>>> log4j3 try to co-exist would be an unmitigated disaster. Commons can
> >>>> happily get
> >>>> away with that. Log4j cannot.
> >>>>
> >>>> If an application had both log4j2 and log4j3 jars present they would
> end
> >>>> up with
> >>>> multiple LoggerContexts, multiple Configurations, and multiple
> Appender
> >>>> Managers
> >>>> where today there is only a single one. That would mean two instances
> of
> >>>> the same
> >>>> configuration file would be active at once. So when it is time to
> >>>> rollover it would
> >>>> be performed twice instead of once as a simple example. For this
> reason
> >>>> we
> >>>> CANNOT break backward compatibility.
> >>>>
> >>>> However, we are talking about runtime backward compatibility. The
> Plugin
> >>>> system
> >>>> was changed internally in 3.0 so that plugins compiled with 3.0 use
> >>>> ServiceLoader
> >>>> instead of the data file. However, it will still find and use 2.x
> plugins
> >>>> when they are
> >>>> present and can be located.
> >>>>
> >>>> The meaning of this should be clear. It is 3.0 because to take
> advantage
> >>>> of its
> >>>> features you may have to make code changes. But it will tolerate code
> >>>> that was
> >>>> compiled for 2.x.
> >>>>
> >>>> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
> >>>> 1. Plugins must be compiled with 3.0 to use the ServiceLoader
> packaging.
> >>>> 2. It requires Java 11. We still need to support Java 8.
> >>>> 3. It fully supports JPMS. Release 2.x does not. It is likely that
> >>>> applications with
> >>>> multiple Module Layers might not be able to find all the plugins.
> Adding
> >>>> full JPMS
> >>>> support to 2.x simply isn’t possible.
> >>>> 4. It will be introducing new DI injection features not present in
> 2.x.
> >>>>
> >>>> Major releases do not imply that you are completely breaking backward
> >>>> compatibility.
> >>>> They imply that some kind of compatibility is broken, which we are
> doing
> >>>> by
> >>>> requiring coding changes to Plugins to compile with 3.0. This means we
> >>>> need to
> >>>> leave in any classes or methods that existing plugins might have
> used. It
> >>>> means
> >>>> we have to continue using our own Supplier unless it can be verified
> that
> >>>> an
> >>>> application using the Supplier in 2.x can run with 3.0 even if it is
> >>>> converted to
> >>>> java.util.function.Supplier. I have no idea if the code the compiler
> >>>> generates
> >>>> for lambdas actually implements the declared interface or not.
> >>>>
> >>>> Log4j 3.0 is a major change. But that doesn’t mean we can screw our
> users
> >>>> by
> >>>> breaking everything.
> >>>>
> >>>> Ralph
> >>>>
> >>>>
> >>>>
> >>>>> On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> These are all IMOs of course, YMMV:
> >>>>> - What's the rush to 3.0?
> >>>>>
> >>>>> - I'm all for breaking up the core and other artifacts into more
> >>>>> artifacts based on their dependencies requirement such that depending
> >>>>> on Log4j 3 does not "suck in the world", for example, I should be
> able
> >>>>> to depend on a currently non-existent "log4j3-console" and only bring
> >>>>> in a tiny bit of code (API, a tiny core, and no plugin system). I did
> >>>>> a fair amount of breaking up of various artifacts a while back.
> >>>>>
> >>>>> - 3.0 is a MAJOR release that gives us the opportunity to drop
> >>>>> deprecated APIs and code like our custom functional interfaces:
> >>>>> Supplier and so on. If we do not clean up, then there is no point in
> a
> >>>>> major release. Basically, I expect to break binary and source
> >>>>> compatibility.
> >>>>>
> >>>>> - 3.0 must be in a new package namespace and new Maven coordinates. I
> >>>>> MUST be able to run Log4j 1, 2, and 3 in the same class loader. I can
> >>>>> already run Log4j 1 and 2 side by side which is good.
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>> On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <
> volkan.yazici@gmail.com>
> >>>> wrote:
> >>>>>>
> >>>>>> Ralph, count me in for such a change. I really want to have separate
> >>>>>> sub-projects for such modules. This will extremely speed up
> >>>> build/release
> >>>>>> times too, which is nowadays of uttermost importance to my peace of
> >>>> mind
> >>>>>> while developing.
> >>>>>>
> >>>>>> This said, I am reluctant about such a major change when we are this
> >>>> close
> >>>>>> to the 3.0.0 release. I guess this would definitely postpone the
> 3.0.0
> >>>>>> release to 2022. This will probably break the backward
> compatibility at
> >>>>>> least for the artifact groupId, am I wrong? Not to mention that the
> >>>> entire
> >>>>>> website needs to be adapted to this multi-project setup too. Is
> there
> >>>>>> anything else?
> >>>>>>
> >>>>>> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <
> ralph.goers@dslextreme.com
> >>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Yeah - I have proposed moving all these extra integrations to a
> >>>> separate
> >>>>>>> repo but
> >>>>>>> I’ve never gotten consensus. I’d prefer to have a project like
> >>>>>>> log4j-pubsub where
> >>>>>>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
> >>>> nosql
> >>>>>>> modules, etc.
> >>>>>>> The problem seems to be that some people believe that we would have
> >>>> to cut
> >>>>>>> a
> >>>>>>> release of those every time we do a log4j release.
> >>>>>>>
> >>>>>>> If we were to do that 3.0 would be the right time.
> >>>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >
>
>
>
Re: Breaking up modules into separate sub-projects
Posted by Ralph Goers <ra...@dslextreme.com>.
No, and to be honest I am not particularly interested in moving away from Maven,
despite its limitations.
I am not sure what we would need Jira tickets for. Creating new GitHub repos
is self service I believe. The web site work is going to be a bunch of manual
effort to get the site the way we want it. We also still have to agree on how
we want it to support both 2.x and 3.x.
My suggestion for the web site would be to have a main site that applies to
both and then have it link to version specific information. I would suggest that
the main log4j web site should be pulled out of the log4j build and move into
logging-log4j-site directly. I would think that pretty much the only stuff that
would remain in the version specific sites would be the stuff generated by the
maven site plugin.
Gary, we already have GitHub Actions set up for Log4j. We also have Jenkins
jobs. I like having both simply because we can get more coverage.
Ralph
> On Jun 11, 2021, at 2:38 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Bazel could be interesting, but does anyone here know how to configure it?
>
> On Fri, 11 Jun 2021 at 15:00, Volkan Yazıcı <vo...@gmail.com> wrote:
>>
>> Since all of us are on board with the idea – except Gary, whom I will
>> address below – shall we work out the structuring? I already shared my
>> proposal. What is your preference? Once we agree on that, I can create
>> relevant Jira tickets, also for the website & manual updates. I can take
>> the responsibility of executing the plan.
>>
>> Gary, I agree with your concerns regarding the build tool. Right now there
>> are ~50 modules in the master. As long as we execute each module's tests
>> sequentially, which is inevitable in Maven and Gradle, I don't think we can
>> shave that down to 10 minutes or so. Not to mention the compile time
>> itself. Unless we migrate to something substantially fine-grained (e.g.,
>> Bazel), I can't think of this happening with Maven or Gradle. Migrating to
>> such exotic solutions have their own trade-offs too.
>>
>> On Fri, Jun 11, 2021 at 10:29 AM Volkan Yazıcı <vo...@gmail.com>
>> wrote:
>>
>>> To start the discussion for breaking up the modules into separate
>>> projects, I propose the following structure:
>>>
>>> *logging-log4j*
>>> log4j-1.2-api
>>> log4j-api
>>> log4j-bom
>>> log4j-core
>>> log4j-core-its
>>> log4j-gctests
>>> log4j-iostreams
>>> log4j-layout-template-json
>>> log4j-perf
>>> log4j-plugins
>>>
>>> *logging-log4j-appender*
>>> log4j-cassandra
>>> log4j-couchdb
>>> log4j-csv
>>> log4j-flume-ng
>>> log4j-mongodb3
>>> log4j-mongodb4
>>> log4j-smtp
>>>
>>> *logging-log4j-appender-jdbc*
>>> log4j-jdbc (?)
>>> log4j-jdbc-dbcp2 (?)
>>> log4j-jpa
>>>
>>> *logging-log4j-appender-queue*
>>> log4j-jeromq
>>> log4j-jms
>>> log4j-kafka
>>> log4j-redis
>>>
>>> *logging-log4j-binding*
>>> log4j-jcl
>>> log4j-jpl
>>> log4j-jul
>>> log4j-liquibase
>>> log4j-slf4j18-impl
>>> log4j-slf4j-impl
>>> log4j-to-slf4j
>>>
>>> *logging-log4j-container*
>>> log4j-docker
>>> log4j-kubernetes
>>>
>>> *logging-log4j-gui*
>>> log4j-jmx-gui
>>>
>>> *logging-log4j-jee*
>>> log4j-appserver
>>> log4j-taglib
>>> log4j-web
>>>
>>> *logging-log4j-layout-jackson*
>>> log4j-layout-jackson
>>> log4j-layout-jackson-json
>>> log4j-layout-jackson-xml
>>> log4j-layout-jackson-yaml
>>>
>>> *logging-log4j-osgi*
>>> log4j-osgi
>>>
>>> *logging-log4j-spring*
>>> log4j-spring-boot
>>> log4j-spring-cloud-config
>>>
>>> Note that above breakdown contains every available module in master,
>>> except log4j-samples, which has the following sub-modules:
>>>
>>> log4j-samples-loggerProperties (contains 2 very trivial example classes,
>>> log4j-core [tests] contains more comprehensive alternatives)
>>> log4j-samples-flume-remote (flume-specific)
>>> log4j-samples-flume-embedded (flume-specific)
>>> log4j-samples-flume-common (flume-specific)
>>> log4j-samples-configuration (contains 3 very trivial example classes,
>>> log4j-core [tests] contains more comprehensive alternatives)
>>>
>>> I propose removing log4j-samples module and, if necessary, moving
>>> Flume-related parts to the log4j-flume-ng.
>>>
>>> I have kept log4j-layout-template-json in the logging-log4j project, since
>>> it has no external dependencies. This said, I am okay with moving it to a
>>> separate logging-log4j-layout project.
>>>
>>> Please share your remarks. Eventually, I want to translate this into a
>>> JIRA ticket.
>>>
>>> Kind regards.
>>>
>>> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> Gary,
>>>>
>>>> I am -1 to almost every item on your list.
>>>>
>>>> When I said break up I meant mostly moving most everything outside of
>>>> log4j-core,
>>>> log4j-api, and log4j-plugins into separate repos such as
>>>> logging-log4j-nosql,
>>>> logging-log4j-pubsub, etc. These would not require groupId or artifactId
>>>> changes
>>>> although the versioning would potentially be out of synch with the main
>>>> releases
>>>> as each would be on its own release cycle. This would greatly simplify
>>>> releasing
>>>> core but it would require careful though on what the versions would be
>>>> for the
>>>> “extra” projects.
>>>>
>>>> As for further breaking up core, that should revolve primarily around
>>>> reducing the
>>>> dependencies listed in module-info.java to the bare minimum.
>>>>
>>>> There will be no log4j3. We cannot change groupIds, artifactIds, or
>>>> package names,
>>>> other than what has been done to support JPMS. A world in which a log4j2
>>>> and
>>>> log4j3 try to co-exist would be an unmitigated disaster. Commons can
>>>> happily get
>>>> away with that. Log4j cannot.
>>>>
>>>> If an application had both log4j2 and log4j3 jars present they would end
>>>> up with
>>>> multiple LoggerContexts, multiple Configurations, and multiple Appender
>>>> Managers
>>>> where today there is only a single one. That would mean two instances of
>>>> the same
>>>> configuration file would be active at once. So when it is time to
>>>> rollover it would
>>>> be performed twice instead of once as a simple example. For this reason
>>>> we
>>>> CANNOT break backward compatibility.
>>>>
>>>> However, we are talking about runtime backward compatibility. The Plugin
>>>> system
>>>> was changed internally in 3.0 so that plugins compiled with 3.0 use
>>>> ServiceLoader
>>>> instead of the data file. However, it will still find and use 2.x plugins
>>>> when they are
>>>> present and can be located.
>>>>
>>>> The meaning of this should be clear. It is 3.0 because to take advantage
>>>> of its
>>>> features you may have to make code changes. But it will tolerate code
>>>> that was
>>>> compiled for 2.x.
>>>>
>>>> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
>>>> 1. Plugins must be compiled with 3.0 to use the ServiceLoader packaging.
>>>> 2. It requires Java 11. We still need to support Java 8.
>>>> 3. It fully supports JPMS. Release 2.x does not. It is likely that
>>>> applications with
>>>> multiple Module Layers might not be able to find all the plugins. Adding
>>>> full JPMS
>>>> support to 2.x simply isn’t possible.
>>>> 4. It will be introducing new DI injection features not present in 2.x.
>>>>
>>>> Major releases do not imply that you are completely breaking backward
>>>> compatibility.
>>>> They imply that some kind of compatibility is broken, which we are doing
>>>> by
>>>> requiring coding changes to Plugins to compile with 3.0. This means we
>>>> need to
>>>> leave in any classes or methods that existing plugins might have used. It
>>>> means
>>>> we have to continue using our own Supplier unless it can be verified that
>>>> an
>>>> application using the Supplier in 2.x can run with 3.0 even if it is
>>>> converted to
>>>> java.util.function.Supplier. I have no idea if the code the compiler
>>>> generates
>>>> for lambdas actually implements the declared interface or not.
>>>>
>>>> Log4j 3.0 is a major change. But that doesn’t mean we can screw our users
>>>> by
>>>> breaking everything.
>>>>
>>>> Ralph
>>>>
>>>>
>>>>
>>>>> On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>>
>>>>> These are all IMOs of course, YMMV:
>>>>> - What's the rush to 3.0?
>>>>>
>>>>> - I'm all for breaking up the core and other artifacts into more
>>>>> artifacts based on their dependencies requirement such that depending
>>>>> on Log4j 3 does not "suck in the world", for example, I should be able
>>>>> to depend on a currently non-existent "log4j3-console" and only bring
>>>>> in a tiny bit of code (API, a tiny core, and no plugin system). I did
>>>>> a fair amount of breaking up of various artifacts a while back.
>>>>>
>>>>> - 3.0 is a MAJOR release that gives us the opportunity to drop
>>>>> deprecated APIs and code like our custom functional interfaces:
>>>>> Supplier and so on. If we do not clean up, then there is no point in a
>>>>> major release. Basically, I expect to break binary and source
>>>>> compatibility.
>>>>>
>>>>> - 3.0 must be in a new package namespace and new Maven coordinates. I
>>>>> MUST be able to run Log4j 1, 2, and 3 in the same class loader. I can
>>>>> already run Log4j 1 and 2 side by side which is good.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <vo...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>> Ralph, count me in for such a change. I really want to have separate
>>>>>> sub-projects for such modules. This will extremely speed up
>>>> build/release
>>>>>> times too, which is nowadays of uttermost importance to my peace of
>>>> mind
>>>>>> while developing.
>>>>>>
>>>>>> This said, I am reluctant about such a major change when we are this
>>>> close
>>>>>> to the 3.0.0 release. I guess this would definitely postpone the 3.0.0
>>>>>> release to 2022. This will probably break the backward compatibility at
>>>>>> least for the artifact groupId, am I wrong? Not to mention that the
>>>> entire
>>>>>> website needs to be adapted to this multi-project setup too. Is there
>>>>>> anything else?
>>>>>>
>>>>>> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <ralph.goers@dslextreme.com
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> Yeah - I have proposed moving all these extra integrations to a
>>>> separate
>>>>>>> repo but
>>>>>>> I’ve never gotten consensus. I’d prefer to have a project like
>>>>>>> log4j-pubsub where
>>>>>>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
>>>> nosql
>>>>>>> modules, etc.
>>>>>>> The problem seems to be that some people believe that we would have
>>>> to cut
>>>>>>> a
>>>>>>> release of those every time we do a log4j release.
>>>>>>>
>>>>>>> If we were to do that 3.0 would be the right time.
>>>>>>>
>>>>>
>>>>
>>>>
>>>>
>
Re: Breaking up modules into separate sub-projects
Posted by Matt Sicker <bo...@gmail.com>.
Bazel could be interesting, but does anyone here know how to configure it?
On Fri, 11 Jun 2021 at 15:00, Volkan Yazıcı <vo...@gmail.com> wrote:
>
> Since all of us are on board with the idea – except Gary, whom I will
> address below – shall we work out the structuring? I already shared my
> proposal. What is your preference? Once we agree on that, I can create
> relevant Jira tickets, also for the website & manual updates. I can take
> the responsibility of executing the plan.
>
> Gary, I agree with your concerns regarding the build tool. Right now there
> are ~50 modules in the master. As long as we execute each module's tests
> sequentially, which is inevitable in Maven and Gradle, I don't think we can
> shave that down to 10 minutes or so. Not to mention the compile time
> itself. Unless we migrate to something substantially fine-grained (e.g.,
> Bazel), I can't think of this happening with Maven or Gradle. Migrating to
> such exotic solutions have their own trade-offs too.
>
> On Fri, Jun 11, 2021 at 10:29 AM Volkan Yazıcı <vo...@gmail.com>
> wrote:
>
> > To start the discussion for breaking up the modules into separate
> > projects, I propose the following structure:
> >
> > *logging-log4j*
> > log4j-1.2-api
> > log4j-api
> > log4j-bom
> > log4j-core
> > log4j-core-its
> > log4j-gctests
> > log4j-iostreams
> > log4j-layout-template-json
> > log4j-perf
> > log4j-plugins
> >
> > *logging-log4j-appender*
> > log4j-cassandra
> > log4j-couchdb
> > log4j-csv
> > log4j-flume-ng
> > log4j-mongodb3
> > log4j-mongodb4
> > log4j-smtp
> >
> > *logging-log4j-appender-jdbc*
> > log4j-jdbc (?)
> > log4j-jdbc-dbcp2 (?)
> > log4j-jpa
> >
> > *logging-log4j-appender-queue*
> > log4j-jeromq
> > log4j-jms
> > log4j-kafka
> > log4j-redis
> >
> > *logging-log4j-binding*
> > log4j-jcl
> > log4j-jpl
> > log4j-jul
> > log4j-liquibase
> > log4j-slf4j18-impl
> > log4j-slf4j-impl
> > log4j-to-slf4j
> >
> > *logging-log4j-container*
> > log4j-docker
> > log4j-kubernetes
> >
> > *logging-log4j-gui*
> > log4j-jmx-gui
> >
> > *logging-log4j-jee*
> > log4j-appserver
> > log4j-taglib
> > log4j-web
> >
> > *logging-log4j-layout-jackson*
> > log4j-layout-jackson
> > log4j-layout-jackson-json
> > log4j-layout-jackson-xml
> > log4j-layout-jackson-yaml
> >
> > *logging-log4j-osgi*
> > log4j-osgi
> >
> > *logging-log4j-spring*
> > log4j-spring-boot
> > log4j-spring-cloud-config
> >
> > Note that above breakdown contains every available module in master,
> > except log4j-samples, which has the following sub-modules:
> >
> > log4j-samples-loggerProperties (contains 2 very trivial example classes,
> > log4j-core [tests] contains more comprehensive alternatives)
> > log4j-samples-flume-remote (flume-specific)
> > log4j-samples-flume-embedded (flume-specific)
> > log4j-samples-flume-common (flume-specific)
> > log4j-samples-configuration (contains 3 very trivial example classes,
> > log4j-core [tests] contains more comprehensive alternatives)
> >
> > I propose removing log4j-samples module and, if necessary, moving
> > Flume-related parts to the log4j-flume-ng.
> >
> > I have kept log4j-layout-template-json in the logging-log4j project, since
> > it has no external dependencies. This said, I am okay with moving it to a
> > separate logging-log4j-layout project.
> >
> > Please share your remarks. Eventually, I want to translate this into a
> > JIRA ticket.
> >
> > Kind regards.
> >
> > On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> >> Gary,
> >>
> >> I am -1 to almost every item on your list.
> >>
> >> When I said break up I meant mostly moving most everything outside of
> >> log4j-core,
> >> log4j-api, and log4j-plugins into separate repos such as
> >> logging-log4j-nosql,
> >> logging-log4j-pubsub, etc. These would not require groupId or artifactId
> >> changes
> >> although the versioning would potentially be out of synch with the main
> >> releases
> >> as each would be on its own release cycle. This would greatly simplify
> >> releasing
> >> core but it would require careful though on what the versions would be
> >> for the
> >> “extra” projects.
> >>
> >> As for further breaking up core, that should revolve primarily around
> >> reducing the
> >> dependencies listed in module-info.java to the bare minimum.
> >>
> >> There will be no log4j3. We cannot change groupIds, artifactIds, or
> >> package names,
> >> other than what has been done to support JPMS. A world in which a log4j2
> >> and
> >> log4j3 try to co-exist would be an unmitigated disaster. Commons can
> >> happily get
> >> away with that. Log4j cannot.
> >>
> >> If an application had both log4j2 and log4j3 jars present they would end
> >> up with
> >> multiple LoggerContexts, multiple Configurations, and multiple Appender
> >> Managers
> >> where today there is only a single one. That would mean two instances of
> >> the same
> >> configuration file would be active at once. So when it is time to
> >> rollover it would
> >> be performed twice instead of once as a simple example. For this reason
> >> we
> >> CANNOT break backward compatibility.
> >>
> >> However, we are talking about runtime backward compatibility. The Plugin
> >> system
> >> was changed internally in 3.0 so that plugins compiled with 3.0 use
> >> ServiceLoader
> >> instead of the data file. However, it will still find and use 2.x plugins
> >> when they are
> >> present and can be located.
> >>
> >> The meaning of this should be clear. It is 3.0 because to take advantage
> >> of its
> >> features you may have to make code changes. But it will tolerate code
> >> that was
> >> compiled for 2.x.
> >>
> >> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
> >> 1. Plugins must be compiled with 3.0 to use the ServiceLoader packaging.
> >> 2. It requires Java 11. We still need to support Java 8.
> >> 3. It fully supports JPMS. Release 2.x does not. It is likely that
> >> applications with
> >> multiple Module Layers might not be able to find all the plugins. Adding
> >> full JPMS
> >> support to 2.x simply isn’t possible.
> >> 4. It will be introducing new DI injection features not present in 2.x.
> >>
> >> Major releases do not imply that you are completely breaking backward
> >> compatibility.
> >> They imply that some kind of compatibility is broken, which we are doing
> >> by
> >> requiring coding changes to Plugins to compile with 3.0. This means we
> >> need to
> >> leave in any classes or methods that existing plugins might have used. It
> >> means
> >> we have to continue using our own Supplier unless it can be verified that
> >> an
> >> application using the Supplier in 2.x can run with 3.0 even if it is
> >> converted to
> >> java.util.function.Supplier. I have no idea if the code the compiler
> >> generates
> >> for lambdas actually implements the declared interface or not.
> >>
> >> Log4j 3.0 is a major change. But that doesn’t mean we can screw our users
> >> by
> >> breaking everything.
> >>
> >> Ralph
> >>
> >>
> >>
> >> > On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
> >> wrote:
> >> >
> >> > These are all IMOs of course, YMMV:
> >> > - What's the rush to 3.0?
> >> >
> >> > - I'm all for breaking up the core and other artifacts into more
> >> > artifacts based on their dependencies requirement such that depending
> >> > on Log4j 3 does not "suck in the world", for example, I should be able
> >> > to depend on a currently non-existent "log4j3-console" and only bring
> >> > in a tiny bit of code (API, a tiny core, and no plugin system). I did
> >> > a fair amount of breaking up of various artifacts a while back.
> >> >
> >> > - 3.0 is a MAJOR release that gives us the opportunity to drop
> >> > deprecated APIs and code like our custom functional interfaces:
> >> > Supplier and so on. If we do not clean up, then there is no point in a
> >> > major release. Basically, I expect to break binary and source
> >> > compatibility.
> >> >
> >> > - 3.0 must be in a new package namespace and new Maven coordinates. I
> >> > MUST be able to run Log4j 1, 2, and 3 in the same class loader. I can
> >> > already run Log4j 1 and 2 side by side which is good.
> >> >
> >> > Gary
> >> >
> >> > On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <vo...@gmail.com>
> >> wrote:
> >> >>
> >> >> Ralph, count me in for such a change. I really want to have separate
> >> >> sub-projects for such modules. This will extremely speed up
> >> build/release
> >> >> times too, which is nowadays of uttermost importance to my peace of
> >> mind
> >> >> while developing.
> >> >>
> >> >> This said, I am reluctant about such a major change when we are this
> >> close
> >> >> to the 3.0.0 release. I guess this would definitely postpone the 3.0.0
> >> >> release to 2022. This will probably break the backward compatibility at
> >> >> least for the artifact groupId, am I wrong? Not to mention that the
> >> entire
> >> >> website needs to be adapted to this multi-project setup too. Is there
> >> >> anything else?
> >> >>
> >> >> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <ralph.goers@dslextreme.com
> >> >
> >> >> wrote:
> >> >>
> >> >>> Yeah - I have proposed moving all these extra integrations to a
> >> separate
> >> >>> repo but
> >> >>> I’ve never gotten consensus. I’d prefer to have a project like
> >> >>> log4j-pubsub where
> >> >>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
> >> nosql
> >> >>> modules, etc.
> >> >>> The problem seems to be that some people believe that we would have
> >> to cut
> >> >>> a
> >> >>> release of those every time we do a log4j release.
> >> >>>
> >> >>> If we were to do that 3.0 would be the right time.
> >> >>>
> >> >
> >>
> >>
> >>
Re: Breaking up modules into separate sub-projects
Posted by Volkan Yazıcı <vo...@gmail.com>.
Since all of us are on board with the idea – except Gary, whom I will
address below – shall we work out the structuring? I already shared my
proposal. What is your preference? Once we agree on that, I can create
relevant Jira tickets, also for the website & manual updates. I can take
the responsibility of executing the plan.
Gary, I agree with your concerns regarding the build tool. Right now there
are ~50 modules in the master. As long as we execute each module's tests
sequentially, which is inevitable in Maven and Gradle, I don't think we can
shave that down to 10 minutes or so. Not to mention the compile time
itself. Unless we migrate to something substantially fine-grained (e.g.,
Bazel), I can't think of this happening with Maven or Gradle. Migrating to
such exotic solutions have their own trade-offs too.
On Fri, Jun 11, 2021 at 10:29 AM Volkan Yazıcı <vo...@gmail.com>
wrote:
> To start the discussion for breaking up the modules into separate
> projects, I propose the following structure:
>
> *logging-log4j*
> log4j-1.2-api
> log4j-api
> log4j-bom
> log4j-core
> log4j-core-its
> log4j-gctests
> log4j-iostreams
> log4j-layout-template-json
> log4j-perf
> log4j-plugins
>
> *logging-log4j-appender*
> log4j-cassandra
> log4j-couchdb
> log4j-csv
> log4j-flume-ng
> log4j-mongodb3
> log4j-mongodb4
> log4j-smtp
>
> *logging-log4j-appender-jdbc*
> log4j-jdbc (?)
> log4j-jdbc-dbcp2 (?)
> log4j-jpa
>
> *logging-log4j-appender-queue*
> log4j-jeromq
> log4j-jms
> log4j-kafka
> log4j-redis
>
> *logging-log4j-binding*
> log4j-jcl
> log4j-jpl
> log4j-jul
> log4j-liquibase
> log4j-slf4j18-impl
> log4j-slf4j-impl
> log4j-to-slf4j
>
> *logging-log4j-container*
> log4j-docker
> log4j-kubernetes
>
> *logging-log4j-gui*
> log4j-jmx-gui
>
> *logging-log4j-jee*
> log4j-appserver
> log4j-taglib
> log4j-web
>
> *logging-log4j-layout-jackson*
> log4j-layout-jackson
> log4j-layout-jackson-json
> log4j-layout-jackson-xml
> log4j-layout-jackson-yaml
>
> *logging-log4j-osgi*
> log4j-osgi
>
> *logging-log4j-spring*
> log4j-spring-boot
> log4j-spring-cloud-config
>
> Note that above breakdown contains every available module in master,
> except log4j-samples, which has the following sub-modules:
>
> log4j-samples-loggerProperties (contains 2 very trivial example classes,
> log4j-core [tests] contains more comprehensive alternatives)
> log4j-samples-flume-remote (flume-specific)
> log4j-samples-flume-embedded (flume-specific)
> log4j-samples-flume-common (flume-specific)
> log4j-samples-configuration (contains 3 very trivial example classes,
> log4j-core [tests] contains more comprehensive alternatives)
>
> I propose removing log4j-samples module and, if necessary, moving
> Flume-related parts to the log4j-flume-ng.
>
> I have kept log4j-layout-template-json in the logging-log4j project, since
> it has no external dependencies. This said, I am okay with moving it to a
> separate logging-log4j-layout project.
>
> Please share your remarks. Eventually, I want to translate this into a
> JIRA ticket.
>
> Kind regards.
>
> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> Gary,
>>
>> I am -1 to almost every item on your list.
>>
>> When I said break up I meant mostly moving most everything outside of
>> log4j-core,
>> log4j-api, and log4j-plugins into separate repos such as
>> logging-log4j-nosql,
>> logging-log4j-pubsub, etc. These would not require groupId or artifactId
>> changes
>> although the versioning would potentially be out of synch with the main
>> releases
>> as each would be on its own release cycle. This would greatly simplify
>> releasing
>> core but it would require careful though on what the versions would be
>> for the
>> “extra” projects.
>>
>> As for further breaking up core, that should revolve primarily around
>> reducing the
>> dependencies listed in module-info.java to the bare minimum.
>>
>> There will be no log4j3. We cannot change groupIds, artifactIds, or
>> package names,
>> other than what has been done to support JPMS. A world in which a log4j2
>> and
>> log4j3 try to co-exist would be an unmitigated disaster. Commons can
>> happily get
>> away with that. Log4j cannot.
>>
>> If an application had both log4j2 and log4j3 jars present they would end
>> up with
>> multiple LoggerContexts, multiple Configurations, and multiple Appender
>> Managers
>> where today there is only a single one. That would mean two instances of
>> the same
>> configuration file would be active at once. So when it is time to
>> rollover it would
>> be performed twice instead of once as a simple example. For this reason
>> we
>> CANNOT break backward compatibility.
>>
>> However, we are talking about runtime backward compatibility. The Plugin
>> system
>> was changed internally in 3.0 so that plugins compiled with 3.0 use
>> ServiceLoader
>> instead of the data file. However, it will still find and use 2.x plugins
>> when they are
>> present and can be located.
>>
>> The meaning of this should be clear. It is 3.0 because to take advantage
>> of its
>> features you may have to make code changes. But it will tolerate code
>> that was
>> compiled for 2.x.
>>
>> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
>> 1. Plugins must be compiled with 3.0 to use the ServiceLoader packaging.
>> 2. It requires Java 11. We still need to support Java 8.
>> 3. It fully supports JPMS. Release 2.x does not. It is likely that
>> applications with
>> multiple Module Layers might not be able to find all the plugins. Adding
>> full JPMS
>> support to 2.x simply isn’t possible.
>> 4. It will be introducing new DI injection features not present in 2.x.
>>
>> Major releases do not imply that you are completely breaking backward
>> compatibility.
>> They imply that some kind of compatibility is broken, which we are doing
>> by
>> requiring coding changes to Plugins to compile with 3.0. This means we
>> need to
>> leave in any classes or methods that existing plugins might have used. It
>> means
>> we have to continue using our own Supplier unless it can be verified that
>> an
>> application using the Supplier in 2.x can run with 3.0 even if it is
>> converted to
>> java.util.function.Supplier. I have no idea if the code the compiler
>> generates
>> for lambdas actually implements the declared interface or not.
>>
>> Log4j 3.0 is a major change. But that doesn’t mean we can screw our users
>> by
>> breaking everything.
>>
>> Ralph
>>
>>
>>
>> > On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> >
>> > These are all IMOs of course, YMMV:
>> > - What's the rush to 3.0?
>> >
>> > - I'm all for breaking up the core and other artifacts into more
>> > artifacts based on their dependencies requirement such that depending
>> > on Log4j 3 does not "suck in the world", for example, I should be able
>> > to depend on a currently non-existent "log4j3-console" and only bring
>> > in a tiny bit of code (API, a tiny core, and no plugin system). I did
>> > a fair amount of breaking up of various artifacts a while back.
>> >
>> > - 3.0 is a MAJOR release that gives us the opportunity to drop
>> > deprecated APIs and code like our custom functional interfaces:
>> > Supplier and so on. If we do not clean up, then there is no point in a
>> > major release. Basically, I expect to break binary and source
>> > compatibility.
>> >
>> > - 3.0 must be in a new package namespace and new Maven coordinates. I
>> > MUST be able to run Log4j 1, 2, and 3 in the same class loader. I can
>> > already run Log4j 1 and 2 side by side which is good.
>> >
>> > Gary
>> >
>> > On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <vo...@gmail.com>
>> wrote:
>> >>
>> >> Ralph, count me in for such a change. I really want to have separate
>> >> sub-projects for such modules. This will extremely speed up
>> build/release
>> >> times too, which is nowadays of uttermost importance to my peace of
>> mind
>> >> while developing.
>> >>
>> >> This said, I am reluctant about such a major change when we are this
>> close
>> >> to the 3.0.0 release. I guess this would definitely postpone the 3.0.0
>> >> release to 2022. This will probably break the backward compatibility at
>> >> least for the artifact groupId, am I wrong? Not to mention that the
>> entire
>> >> website needs to be adapted to this multi-project setup too. Is there
>> >> anything else?
>> >>
>> >> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <ralph.goers@dslextreme.com
>> >
>> >> wrote:
>> >>
>> >>> Yeah - I have proposed moving all these extra integrations to a
>> separate
>> >>> repo but
>> >>> I’ve never gotten consensus. I’d prefer to have a project like
>> >>> log4j-pubsub where
>> >>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the
>> nosql
>> >>> modules, etc.
>> >>> The problem seems to be that some people believe that we would have
>> to cut
>> >>> a
>> >>> release of those every time we do a log4j release.
>> >>>
>> >>> If we were to do that 3.0 would be the right time.
>> >>>
>> >
>>
>>
>>
Re: Breaking up modules into separate sub-projects
Posted by Volkan Yazıcı <vo...@gmail.com>.
To start the discussion for breaking up the modules into separate projects,
I propose the following structure:
*logging-log4j*
log4j-1.2-api
log4j-api
log4j-bom
log4j-core
log4j-core-its
log4j-gctests
log4j-iostreams
log4j-layout-template-json
log4j-perf
log4j-plugins
*logging-log4j-appender*
log4j-cassandra
log4j-couchdb
log4j-csv
log4j-flume-ng
log4j-mongodb3
log4j-mongodb4
log4j-smtp
*logging-log4j-appender-jdbc*
log4j-jdbc (?)
log4j-jdbc-dbcp2 (?)
log4j-jpa
*logging-log4j-appender-queue*
log4j-jeromq
log4j-jms
log4j-kafka
log4j-redis
*logging-log4j-binding*
log4j-jcl
log4j-jpl
log4j-jul
log4j-liquibase
log4j-slf4j18-impl
log4j-slf4j-impl
log4j-to-slf4j
*logging-log4j-container*
log4j-docker
log4j-kubernetes
*logging-log4j-gui*
log4j-jmx-gui
*logging-log4j-jee*
log4j-appserver
log4j-taglib
log4j-web
*logging-log4j-layout-jackson*
log4j-layout-jackson
log4j-layout-jackson-json
log4j-layout-jackson-xml
log4j-layout-jackson-yaml
*logging-log4j-osgi*
log4j-osgi
*logging-log4j-spring*
log4j-spring-boot
log4j-spring-cloud-config
Note that above breakdown contains every available module in master, except
log4j-samples, which has the following sub-modules:
log4j-samples-loggerProperties (contains 2 very trivial example classes,
log4j-core [tests] contains more comprehensive alternatives)
log4j-samples-flume-remote (flume-specific)
log4j-samples-flume-embedded (flume-specific)
log4j-samples-flume-common (flume-specific)
log4j-samples-configuration (contains 3 very trivial example classes,
log4j-core [tests] contains more comprehensive alternatives)
I propose removing log4j-samples module and, if necessary, moving
Flume-related parts to the log4j-flume-ng.
I have kept log4j-layout-template-json in the logging-log4j project, since
it has no external dependencies. This said, I am okay with moving it to a
separate logging-log4j-layout project.
Please share your remarks. Eventually, I want to translate this into a JIRA
ticket.
Kind regards.
On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> Gary,
>
> I am -1 to almost every item on your list.
>
> When I said break up I meant mostly moving most everything outside of
> log4j-core,
> log4j-api, and log4j-plugins into separate repos such as
> logging-log4j-nosql,
> logging-log4j-pubsub, etc. These would not require groupId or artifactId
> changes
> although the versioning would potentially be out of synch with the main
> releases
> as each would be on its own release cycle. This would greatly simplify
> releasing
> core but it would require careful though on what the versions would be for
> the
> “extra” projects.
>
> As for further breaking up core, that should revolve primarily around
> reducing the
> dependencies listed in module-info.java to the bare minimum.
>
> There will be no log4j3. We cannot change groupIds, artifactIds, or
> package names,
> other than what has been done to support JPMS. A world in which a log4j2
> and
> log4j3 try to co-exist would be an unmitigated disaster. Commons can
> happily get
> away with that. Log4j cannot.
>
> If an application had both log4j2 and log4j3 jars present they would end
> up with
> multiple LoggerContexts, multiple Configurations, and multiple Appender
> Managers
> where today there is only a single one. That would mean two instances of
> the same
> configuration file would be active at once. So when it is time to rollover
> it would
> be performed twice instead of once as a simple example. For this reason we
> CANNOT break backward compatibility.
>
> However, we are talking about runtime backward compatibility. The Plugin
> system
> was changed internally in 3.0 so that plugins compiled with 3.0 use
> ServiceLoader
> instead of the data file. However, it will still find and use 2.x plugins
> when they are
> present and can be located.
>
> The meaning of this should be clear. It is 3.0 because to take advantage
> of its
> features you may have to make code changes. But it will tolerate code that
> was
> compiled for 2.x.
>
> The reasons why it is 3.0 and not a simple upgrade to 2.x are:
> 1. Plugins must be compiled with 3.0 to use the ServiceLoader packaging.
> 2. It requires Java 11. We still need to support Java 8.
> 3. It fully supports JPMS. Release 2.x does not. It is likely that
> applications with
> multiple Module Layers might not be able to find all the plugins. Adding
> full JPMS
> support to 2.x simply isn’t possible.
> 4. It will be introducing new DI injection features not present in 2.x.
>
> Major releases do not imply that you are completely breaking backward
> compatibility.
> They imply that some kind of compatibility is broken, which we are doing
> by
> requiring coding changes to Plugins to compile with 3.0. This means we
> need to
> leave in any classes or methods that existing plugins might have used. It
> means
> we have to continue using our own Supplier unless it can be verified that
> an
> application using the Supplier in 2.x can run with 3.0 even if it is
> converted to
> java.util.function.Supplier. I have no idea if the code the compiler
> generates
> for lambdas actually implements the declared interface or not.
>
> Log4j 3.0 is a major change. But that doesn’t mean we can screw our users
> by
> breaking everything.
>
> Ralph
>
>
>
> > On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > These are all IMOs of course, YMMV:
> > - What's the rush to 3.0?
> >
> > - I'm all for breaking up the core and other artifacts into more
> > artifacts based on their dependencies requirement such that depending
> > on Log4j 3 does not "suck in the world", for example, I should be able
> > to depend on a currently non-existent "log4j3-console" and only bring
> > in a tiny bit of code (API, a tiny core, and no plugin system). I did
> > a fair amount of breaking up of various artifacts a while back.
> >
> > - 3.0 is a MAJOR release that gives us the opportunity to drop
> > deprecated APIs and code like our custom functional interfaces:
> > Supplier and so on. If we do not clean up, then there is no point in a
> > major release. Basically, I expect to break binary and source
> > compatibility.
> >
> > - 3.0 must be in a new package namespace and new Maven coordinates. I
> > MUST be able to run Log4j 1, 2, and 3 in the same class loader. I can
> > already run Log4j 1 and 2 side by side which is good.
> >
> > Gary
> >
> > On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <vo...@gmail.com>
> wrote:
> >>
> >> Ralph, count me in for such a change. I really want to have separate
> >> sub-projects for such modules. This will extremely speed up
> build/release
> >> times too, which is nowadays of uttermost importance to my peace of mind
> >> while developing.
> >>
> >> This said, I am reluctant about such a major change when we are this
> close
> >> to the 3.0.0 release. I guess this would definitely postpone the 3.0.0
> >> release to 2022. This will probably break the backward compatibility at
> >> least for the artifact groupId, am I wrong? Not to mention that the
> entire
> >> website needs to be adapted to this multi-project setup too. Is there
> >> anything else?
> >>
> >> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <ra...@dslextreme.com>
> >> wrote:
> >>
> >>> Yeah - I have proposed moving all these extra integrations to a
> separate
> >>> repo but
> >>> I’ve never gotten consensus. I’d prefer to have a project like
> >>> log4j-pubsub where
> >>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the nosql
> >>> modules, etc.
> >>> The problem seems to be that some people believe that we would have to
> cut
> >>> a
> >>> release of those every time we do a log4j release.
> >>>
> >>> If we were to do that 3.0 would be the right time.
> >>>
> >
>
>
>
Re: Breaking up modules into separate sub-projects
Posted by Ralph Goers <ra...@dslextreme.com>.
Gary,
I am -1 to almost every item on your list.
When I said break up I meant mostly moving most everything outside of log4j-core,
log4j-api, and log4j-plugins into separate repos such as logging-log4j-nosql,
logging-log4j-pubsub, etc. These would not require groupId or artifactId changes
although the versioning would potentially be out of synch with the main releases
as each would be on its own release cycle. This would greatly simplify releasing
core but it would require careful though on what the versions would be for the
“extra” projects.
As for further breaking up core, that should revolve primarily around reducing the
dependencies listed in module-info.java to the bare minimum.
There will be no log4j3. We cannot change groupIds, artifactIds, or package names,
other than what has been done to support JPMS. A world in which a log4j2 and
log4j3 try to co-exist would be an unmitigated disaster. Commons can happily get
away with that. Log4j cannot.
If an application had both log4j2 and log4j3 jars present they would end up with
multiple LoggerContexts, multiple Configurations, and multiple Appender Managers
where today there is only a single one. That would mean two instances of the same
configuration file would be active at once. So when it is time to rollover it would
be performed twice instead of once as a simple example. For this reason we
CANNOT break backward compatibility.
However, we are talking about runtime backward compatibility. The Plugin system
was changed internally in 3.0 so that plugins compiled with 3.0 use ServiceLoader
instead of the data file. However, it will still find and use 2.x plugins when they are
present and can be located.
The meaning of this should be clear. It is 3.0 because to take advantage of its
features you may have to make code changes. But it will tolerate code that was
compiled for 2.x.
The reasons why it is 3.0 and not a simple upgrade to 2.x are:
1. Plugins must be compiled with 3.0 to use the ServiceLoader packaging.
2. It requires Java 11. We still need to support Java 8.
3. It fully supports JPMS. Release 2.x does not. It is likely that applications with
multiple Module Layers might not be able to find all the plugins. Adding full JPMS
support to 2.x simply isn’t possible.
4. It will be introducing new DI injection features not present in 2.x.
Major releases do not imply that you are completely breaking backward compatibility.
They imply that some kind of compatibility is broken, which we are doing by
requiring coding changes to Plugins to compile with 3.0. This means we need to
leave in any classes or methods that existing plugins might have used. It means
we have to continue using our own Supplier unless it can be verified that an
application using the Supplier in 2.x can run with 3.0 even if it is converted to
java.util.function.Supplier. I have no idea if the code the compiler generates
for lambdas actually implements the declared interface or not.
Log4j 3.0 is a major change. But that doesn’t mean we can screw our users by
breaking everything.
Ralph
> On Jun 10, 2021, at 6:32 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> These are all IMOs of course, YMMV:
> - What's the rush to 3.0?
>
> - I'm all for breaking up the core and other artifacts into more
> artifacts based on their dependencies requirement such that depending
> on Log4j 3 does not "suck in the world", for example, I should be able
> to depend on a currently non-existent "log4j3-console" and only bring
> in a tiny bit of code (API, a tiny core, and no plugin system). I did
> a fair amount of breaking up of various artifacts a while back.
>
> - 3.0 is a MAJOR release that gives us the opportunity to drop
> deprecated APIs and code like our custom functional interfaces:
> Supplier and so on. If we do not clean up, then there is no point in a
> major release. Basically, I expect to break binary and source
> compatibility.
>
> - 3.0 must be in a new package namespace and new Maven coordinates. I
> MUST be able to run Log4j 1, 2, and 3 in the same class loader. I can
> already run Log4j 1 and 2 side by side which is good.
>
> Gary
>
> On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <vo...@gmail.com> wrote:
>>
>> Ralph, count me in for such a change. I really want to have separate
>> sub-projects for such modules. This will extremely speed up build/release
>> times too, which is nowadays of uttermost importance to my peace of mind
>> while developing.
>>
>> This said, I am reluctant about such a major change when we are this close
>> to the 3.0.0 release. I guess this would definitely postpone the 3.0.0
>> release to 2022. This will probably break the backward compatibility at
>> least for the artifact groupId, am I wrong? Not to mention that the entire
>> website needs to be adapted to this multi-project setup too. Is there
>> anything else?
>>
>> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> Yeah - I have proposed moving all these extra integrations to a separate
>>> repo but
>>> I’ve never gotten consensus. I’d prefer to have a project like
>>> log4j-pubsub where
>>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the nosql
>>> modules, etc.
>>> The problem seems to be that some people believe that we would have to cut
>>> a
>>> release of those every time we do a log4j release.
>>>
>>> If we were to do that 3.0 would be the right time.
>>>
>
Re: Breaking up modules into separate sub-projects
Posted by Gary Gregory <ga...@gmail.com>.
These are all IMOs of course, YMMV:
- What's the rush to 3.0?
- I'm all for breaking up the core and other artifacts into more
artifacts based on their dependencies requirement such that depending
on Log4j 3 does not "suck in the world", for example, I should be able
to depend on a currently non-existent "log4j3-console" and only bring
in a tiny bit of code (API, a tiny core, and no plugin system). I did
a fair amount of breaking up of various artifacts a while back.
- 3.0 is a MAJOR release that gives us the opportunity to drop
deprecated APIs and code like our custom functional interfaces:
Supplier and so on. If we do not clean up, then there is no point in a
major release. Basically, I expect to break binary and source
compatibility.
- 3.0 must be in a new package namespace and new Maven coordinates. I
MUST be able to run Log4j 1, 2, and 3 in the same class loader. I can
already run Log4j 1 and 2 side by side which is good.
Gary
On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı <vo...@gmail.com> wrote:
>
> Ralph, count me in for such a change. I really want to have separate
> sub-projects for such modules. This will extremely speed up build/release
> times too, which is nowadays of uttermost importance to my peace of mind
> while developing.
>
> This said, I am reluctant about such a major change when we are this close
> to the 3.0.0 release. I guess this would definitely postpone the 3.0.0
> release to 2022. This will probably break the backward compatibility at
> least for the artifact groupId, am I wrong? Not to mention that the entire
> website needs to be adapted to this multi-project setup too. Is there
> anything else?
>
> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> > Yeah - I have proposed moving all these extra integrations to a separate
> > repo but
> > I’ve never gotten consensus. I’d prefer to have a project like
> > log4j-pubsub where
> > things like JMS, JeroMQ, etc can go live, log4j-nosql for all the nosql
> > modules, etc.
> > The problem seems to be that some people believe that we would have to cut
> > a
> > release of those every time we do a log4j release.
> >
> > If we were to do that 3.0 would be the right time.
> >
Breaking up modules into separate sub-projects
Posted by Volkan Yazıcı <vo...@gmail.com>.
Ralph, count me in for such a change. I really want to have separate
sub-projects for such modules. This will extremely speed up build/release
times too, which is nowadays of uttermost importance to my peace of mind
while developing.
This said, I am reluctant about such a major change when we are this close
to the 3.0.0 release. I guess this would definitely postpone the 3.0.0
release to 2022. This will probably break the backward compatibility at
least for the artifact groupId, am I wrong? Not to mention that the entire
website needs to be adapted to this multi-project setup too. Is there
anything else?
On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> Yeah - I have proposed moving all these extra integrations to a separate
> repo but
> I’ve never gotten consensus. I’d prefer to have a project like
> log4j-pubsub where
> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the nosql
> modules, etc.
> The problem seems to be that some people believe that we would have to cut
> a
> release of those every time we do a log4j release.
>
> If we were to do that 3.0 would be the right time.
>
Re: [apache/logging-log4j2] Liquibase 4.x Compatibility (#503)
Posted by Volkan Yazıcı <vo...@gmail.com>.
If I understand it correctly, an application, which is Liquibase in this
particular case, created its own logging API rather than using one
available in the market and contributing its implementations to logging
frameworks to support its API. Isn't this, if I may say, ill-advised
approach exactly the thing that logging APIs are trying to overcome?
Further, wouldn't promoting this conflict with the goal of making logger
APIs wider adaptation?
Let's think the other way around: Why doesn't Liquibase simply use the
Log4j API? What is stopping them from doing this? Are there any technical
blockers?
On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> Yeah - I have proposed moving all these extra integrations to a separate
> repo but
> I’ve never gotten consensus. I’d prefer to have a project like
> log4j-pubsub where
> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the nosql
> modules, etc.
> The problem seems to be that some people believe that we would have to cut
> a
> release of those every time we do a log4j release.
>
> If we were to do that 3.0 would be the right time.
>
> Ralph
>
> > On Jun 3, 2021, at 7:46 AM, Matt Sicker <bo...@gmail.com> wrote:
> >
> > It was probably contributed as a logging bridge/adapter similar to the
> > SLF4J, JCL, JUL, etc, modules. Normally I’d say that this is the
> > appropriate place to add anything related to log4j, but there are so many
> > customizations out in the wild (see for instance the Spring Boot
> > initialization stuff), I can’t exactly say that it’s always the best
> idea.
> >
> > On Thu, Jun 3, 2021 at 08:21 Volkan Yazıcı <vo...@gmail.com>
> wrote:
> >
> >> I am just curious, why is the Liquibase logger a part of the Log4j
> project?
> >> Shouldn't Liquibase itself be providing the logging bridges of their
> >> software for certain logging backends?
> >>
> >> On Wed, Jun 2, 2021 at 10:17 PM Nathan Voxland <
> notifications@github.com>
> >> wrote:
> >>
> >>> Overview
> >>>
> >>> Liquibase 3.6 as well as 4.0 introduced API compatibility issues with
> the
> >>> current log4j-liquibase codebase. See liquibase/liquibase#1777
> >>> <https://github.com/liquibase/liquibase/issues/1777>
> >>>
> >>> This updates the code to be compatible with 4.0+ while still supporting
> >>> 3.5 and 3.6+ users.
> >>> ------------------------------
> >>> You can view, comment on, or merge this pull request online at:
> >>>
> >>> https://github.com/apache/logging-log4j2/pull/503
> >>> Commit Summary
> >>>
> >>> - Updated log4j-liquibase to be compatible with both 3.x and 4.x
> >>> versions of Liquibase
> >>> - Updated log4j-liquibase to be compatible with both 3.x and 4.x
> >>> versions of Liquibase
> >>>
> >>> File Changes
> >>>
> >>> - *A*
> >>>
> >>
> log4j-liquibase/src/main/java/liquibase/ext/logging/log4j2/DeprecatedLog4j2Logger.java
> >>> <
> >>
> https://github.com/apache/logging-log4j2/pull/503/files#diff-aabadf00cbeee77ba36f78292fe7dc11fe16c3b46f2a8b64b93c219514fec86b
> >>>
> >>> (189)
> >>> - *M*
> >>>
> >>
> log4j-liquibase/src/main/java/liquibase/ext/logging/log4j2/Log4j2Logger.java
> >>> <
> >>
> https://github.com/apache/logging-log4j2/pull/503/files#diff-a3fb75cc20998f82ba5cb4783d5f57420eead2d5277b6007b8f23554fd25c714
> >>>
> >>> (157)
> >>> - *A*
> >>>
> >>
> log4j-liquibase/src/main/java/liquibase/ext/logging/log4j2/Log4j2LoggerService.java
> >>> <
> >>
> https://github.com/apache/logging-log4j2/pull/503/files#diff-62b7869399bb7251582033dd21d08acc257f56e3cd6bd426bc68e92f67e0ab11
> >>>
> >>> (47)
> >>> - *A*
> >>>
> >>
> log4j-liquibase/src/main/resources/META-INF/services/liquibase.logging.LogService
> >>> <
> >>
> https://github.com/apache/logging-log4j2/pull/503/files#diff-41f6a06104e2662ac0882a53045eb884cd5b9009d1e5de8e847e04b2aa79ac2b
> >>>
> >>> (1)
> >>> - *R*
> >>>
> >>
> log4j-liquibase/src/test/java/liquibase/ext/logging/log4j2/DeprecatedLog4J2LoggerTest.java
> >>> <
> >>
> https://github.com/apache/logging-log4j2/pull/503/files#diff-7b353543266b0e9219b856fac1c3df928764f8a41612e5e59ea3841b75e11d3e
> >>>
> >>> (8)
> >>> - *A*
> >>>
> >>
> log4j-liquibase/src/test/java/liquibase/ext/logging/log4j2/Log4j2LoggerTest.java
> >>> <
> >>
> https://github.com/apache/logging-log4j2/pull/503/files#diff-ae83836593517181c94282dfacab38f16e1741fa3503c1c4a5297753efe4e09d
> >>>
> >>> (86)
> >>> - *M* pom.xml
> >>> <
> >>
> https://github.com/apache/logging-log4j2/pull/503/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8
> >>>
> >>> (3)
> >>>
> >>> Patch Links:
> >>>
> >>> - https://github.com/apache/logging-log4j2/pull/503.patch
> >>> - https://github.com/apache/logging-log4j2/pull/503.diff
> >>>
> >>> —
> >>> You are receiving this because you are subscribed to this thread.
> >>> Reply to this email directly, view it on GitHub
> >>> <https://github.com/apache/logging-log4j2/pull/503>, or unsubscribe
> >>> <
> >>
> https://github.com/notifications/unsubscribe-auth/AAARTSNWLZC4VTOBYVGT4TTTQ2GT3ANCNFSM457M3ARA
> >>>
> >>> .
> >>>
> >>
>
>
>
Re: [apache/logging-log4j2] Liquibase 4.x Compatibility (#503)
Posted by Ralph Goers <ra...@dslextreme.com>.
Yeah - I have proposed moving all these extra integrations to a separate repo but
I’ve never gotten consensus. I’d prefer to have a project like log4j-pubsub where
things like JMS, JeroMQ, etc can go live, log4j-nosql for all the nosql modules, etc.
The problem seems to be that some people believe that we would have to cut a
release of those every time we do a log4j release.
If we were to do that 3.0 would be the right time.
Ralph
> On Jun 3, 2021, at 7:46 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> It was probably contributed as a logging bridge/adapter similar to the
> SLF4J, JCL, JUL, etc, modules. Normally I’d say that this is the
> appropriate place to add anything related to log4j, but there are so many
> customizations out in the wild (see for instance the Spring Boot
> initialization stuff), I can’t exactly say that it’s always the best idea.
>
> On Thu, Jun 3, 2021 at 08:21 Volkan Yazıcı <vo...@gmail.com> wrote:
>
>> I am just curious, why is the Liquibase logger a part of the Log4j project?
>> Shouldn't Liquibase itself be providing the logging bridges of their
>> software for certain logging backends?
>>
>> On Wed, Jun 2, 2021 at 10:17 PM Nathan Voxland <no...@github.com>
>> wrote:
>>
>>> Overview
>>>
>>> Liquibase 3.6 as well as 4.0 introduced API compatibility issues with the
>>> current log4j-liquibase codebase. See liquibase/liquibase#1777
>>> <https://github.com/liquibase/liquibase/issues/1777>
>>>
>>> This updates the code to be compatible with 4.0+ while still supporting
>>> 3.5 and 3.6+ users.
>>> ------------------------------
>>> You can view, comment on, or merge this pull request online at:
>>>
>>> https://github.com/apache/logging-log4j2/pull/503
>>> Commit Summary
>>>
>>> - Updated log4j-liquibase to be compatible with both 3.x and 4.x
>>> versions of Liquibase
>>> - Updated log4j-liquibase to be compatible with both 3.x and 4.x
>>> versions of Liquibase
>>>
>>> File Changes
>>>
>>> - *A*
>>>
>> log4j-liquibase/src/main/java/liquibase/ext/logging/log4j2/DeprecatedLog4j2Logger.java
>>> <
>> https://github.com/apache/logging-log4j2/pull/503/files#diff-aabadf00cbeee77ba36f78292fe7dc11fe16c3b46f2a8b64b93c219514fec86b
>>>
>>> (189)
>>> - *M*
>>>
>> log4j-liquibase/src/main/java/liquibase/ext/logging/log4j2/Log4j2Logger.java
>>> <
>> https://github.com/apache/logging-log4j2/pull/503/files#diff-a3fb75cc20998f82ba5cb4783d5f57420eead2d5277b6007b8f23554fd25c714
>>>
>>> (157)
>>> - *A*
>>>
>> log4j-liquibase/src/main/java/liquibase/ext/logging/log4j2/Log4j2LoggerService.java
>>> <
>> https://github.com/apache/logging-log4j2/pull/503/files#diff-62b7869399bb7251582033dd21d08acc257f56e3cd6bd426bc68e92f67e0ab11
>>>
>>> (47)
>>> - *A*
>>>
>> log4j-liquibase/src/main/resources/META-INF/services/liquibase.logging.LogService
>>> <
>> https://github.com/apache/logging-log4j2/pull/503/files#diff-41f6a06104e2662ac0882a53045eb884cd5b9009d1e5de8e847e04b2aa79ac2b
>>>
>>> (1)
>>> - *R*
>>>
>> log4j-liquibase/src/test/java/liquibase/ext/logging/log4j2/DeprecatedLog4J2LoggerTest.java
>>> <
>> https://github.com/apache/logging-log4j2/pull/503/files#diff-7b353543266b0e9219b856fac1c3df928764f8a41612e5e59ea3841b75e11d3e
>>>
>>> (8)
>>> - *A*
>>>
>> log4j-liquibase/src/test/java/liquibase/ext/logging/log4j2/Log4j2LoggerTest.java
>>> <
>> https://github.com/apache/logging-log4j2/pull/503/files#diff-ae83836593517181c94282dfacab38f16e1741fa3503c1c4a5297753efe4e09d
>>>
>>> (86)
>>> - *M* pom.xml
>>> <
>> https://github.com/apache/logging-log4j2/pull/503/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8
>>>
>>> (3)
>>>
>>> Patch Links:
>>>
>>> - https://github.com/apache/logging-log4j2/pull/503.patch
>>> - https://github.com/apache/logging-log4j2/pull/503.diff
>>>
>>> —
>>> You are receiving this because you are subscribed to this thread.
>>> Reply to this email directly, view it on GitHub
>>> <https://github.com/apache/logging-log4j2/pull/503>, or unsubscribe
>>> <
>> https://github.com/notifications/unsubscribe-auth/AAARTSNWLZC4VTOBYVGT4TTTQ2GT3ANCNFSM457M3ARA
>>>
>>> .
>>>
>>
Re: [apache/logging-log4j2] Liquibase 4.x Compatibility (#503)
Posted by Matt Sicker <bo...@gmail.com>.
It was probably contributed as a logging bridge/adapter similar to the
SLF4J, JCL, JUL, etc, modules. Normally I’d say that this is the
appropriate place to add anything related to log4j, but there are so many
customizations out in the wild (see for instance the Spring Boot
initialization stuff), I can’t exactly say that it’s always the best idea.
On Thu, Jun 3, 2021 at 08:21 Volkan Yazıcı <vo...@gmail.com> wrote:
> I am just curious, why is the Liquibase logger a part of the Log4j project?
> Shouldn't Liquibase itself be providing the logging bridges of their
> software for certain logging backends?
>
> On Wed, Jun 2, 2021 at 10:17 PM Nathan Voxland <no...@github.com>
> wrote:
>
> > Overview
> >
> > Liquibase 3.6 as well as 4.0 introduced API compatibility issues with the
> > current log4j-liquibase codebase. See liquibase/liquibase#1777
> > <https://github.com/liquibase/liquibase/issues/1777>
> >
> > This updates the code to be compatible with 4.0+ while still supporting
> > 3.5 and 3.6+ users.
> > ------------------------------
> > You can view, comment on, or merge this pull request online at:
> >
> > https://github.com/apache/logging-log4j2/pull/503
> > Commit Summary
> >
> > - Updated log4j-liquibase to be compatible with both 3.x and 4.x
> > versions of Liquibase
> > - Updated log4j-liquibase to be compatible with both 3.x and 4.x
> > versions of Liquibase
> >
> > File Changes
> >
> > - *A*
> >
> log4j-liquibase/src/main/java/liquibase/ext/logging/log4j2/DeprecatedLog4j2Logger.java
> > <
> https://github.com/apache/logging-log4j2/pull/503/files#diff-aabadf00cbeee77ba36f78292fe7dc11fe16c3b46f2a8b64b93c219514fec86b
> >
> > (189)
> > - *M*
> >
> log4j-liquibase/src/main/java/liquibase/ext/logging/log4j2/Log4j2Logger.java
> > <
> https://github.com/apache/logging-log4j2/pull/503/files#diff-a3fb75cc20998f82ba5cb4783d5f57420eead2d5277b6007b8f23554fd25c714
> >
> > (157)
> > - *A*
> >
> log4j-liquibase/src/main/java/liquibase/ext/logging/log4j2/Log4j2LoggerService.java
> > <
> https://github.com/apache/logging-log4j2/pull/503/files#diff-62b7869399bb7251582033dd21d08acc257f56e3cd6bd426bc68e92f67e0ab11
> >
> > (47)
> > - *A*
> >
> log4j-liquibase/src/main/resources/META-INF/services/liquibase.logging.LogService
> > <
> https://github.com/apache/logging-log4j2/pull/503/files#diff-41f6a06104e2662ac0882a53045eb884cd5b9009d1e5de8e847e04b2aa79ac2b
> >
> > (1)
> > - *R*
> >
> log4j-liquibase/src/test/java/liquibase/ext/logging/log4j2/DeprecatedLog4J2LoggerTest.java
> > <
> https://github.com/apache/logging-log4j2/pull/503/files#diff-7b353543266b0e9219b856fac1c3df928764f8a41612e5e59ea3841b75e11d3e
> >
> > (8)
> > - *A*
> >
> log4j-liquibase/src/test/java/liquibase/ext/logging/log4j2/Log4j2LoggerTest.java
> > <
> https://github.com/apache/logging-log4j2/pull/503/files#diff-ae83836593517181c94282dfacab38f16e1741fa3503c1c4a5297753efe4e09d
> >
> > (86)
> > - *M* pom.xml
> > <
> https://github.com/apache/logging-log4j2/pull/503/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8
> >
> > (3)
> >
> > Patch Links:
> >
> > - https://github.com/apache/logging-log4j2/pull/503.patch
> > - https://github.com/apache/logging-log4j2/pull/503.diff
> >
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub
> > <https://github.com/apache/logging-log4j2/pull/503>, or unsubscribe
> > <
> https://github.com/notifications/unsubscribe-auth/AAARTSNWLZC4VTOBYVGT4TTTQ2GT3ANCNFSM457M3ARA
> >
> > .
> >
>