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.go...@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 <garydgreg...@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.yaz...@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.go...@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. > >>> > > > > >
