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