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 <ralph.go...@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 <boa...@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ı <volkan.yaz...@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.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. > >>>>>>> > >>>>> > >>>> > >>>> > >>>> > > > > >
