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