I definitely agree with this. This is such a convenience while using Spring.
On Fri, Jun 11, 2021 at 4:07 PM Matt Sicker <boa...@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 <garydgreg...@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.yaz...@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.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. > > > > >>> > > > > > > > > > > > > > > > > > > > > > > >
