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