I mostly agree with this but have two quibbles: 1. The grouping of the components (mostly appenders) seems very arbitrary. I would have expected an appender-nosql that would not include flume, csv, and smtp as those have very little to do with the Cassandra, couchdb, mongodb, or redis appenders (Redis is a key/value store, not a queue). I would also put log4j-perf in its own repo. Flume would either go with Kafka, JMS, etc or in a repo of its own as it is an event transport much as Kafka, etc are. I have no idea where csv and smtp would go.
2. The web site. I want to completely divorce the web site from the release. The web site content should be in logging-log4j2-site. We should figure out a way to handle versioning of the web site content so that pushing a release simply means making that version the default version on the web site, much as we do with the symlink today. But we should be able to continually update the staging and live sites even with content for the next release. I very much disagree with each repo having its own web site. The repos are for our convenience. Having multiple web sites will just make it even harder for users to find stuff. I have no problem reorganizing the manual or rewriting portions of it, but that should be done for its own sake, not to match how we have organized the components into repos. Ralph > On Apr 30, 2022, at 12:09 AM, Matt Sicker <[email protected]> wrote: > > I like that general structure you've proposed. Indeed, migrating the > site to its own repo should help here. Individual repos would then be > easier to cut releases from as there'd be no website to generate > (though we'd need something to update download pages at least). > > If we can set up GitHub Actions to trigger downstream jobs, we could > potentially have changes to the API or similar get integration tested > against other repos. > > On Fri, Apr 29, 2022 at 3:04 PM Volkan Yazıcı <[email protected]> wrote: >> >> I have raised this issue in the past. I even came up with a proposal on the >> repository structure >> <https://lists.apache.org/thread/sdv92pw6m9bst8zzn88jyln8z8ozshw3> to be >> followed. I am a big proponent of breaking up the logging-log4j2 repository >> into multiple ones. The current size of the code base is simply >> incomprehensible and slows down the development cycle tremendously due to >> excessive compilation and test times. >> >> *The proposal* >> >> Let me share the break down I have in mind: >> >> *logging-log4j2-api* >> log4j-1.2-api >> log4j-api >> >> *logging-log4j2* >> log4j-bom >> log4j-core >> log4j-core-its >> log4j-gctests >> log4j-iostreams >> log4j-perf >> log4j-plugins >> >> *logging-log4j2-appender* >> log4j-cassandra >> log4j-couchdb >> log4j-csv >> log4j-flume-ng >> log4j-mongodb3 >> log4j-mongodb4 >> log4j-smtp >> >> *logging-log4j2-appender-jdbc* >> log4j-jdbc (?) >> log4j-jdbc-dbcp2 (?) >> log4j-jpa >> >> *logging-log4j2-appender-queue* >> log4j-jeromq >> log4j-jms >> log4j-kafka >> log4j-redis >> >> *logging-log4j2-binding* >> log4j-jcl >> log4j-jpl >> log4j-jul >> log4j-liquibase >> log4j-slf4j18-impl >> log4j-slf4j-impl >> log4j-to-slf4j >> >> *logging-log4j2-container* >> log4j-docker >> log4j-kubernetes >> >> *logging-log4j2-gui* >> log4j-jmx-gui >> >> *logging-log4j2-jee* >> log4j-appserver >> log4j-taglib >> log4j-web >> >> *logging-log4j2-layout-json* >> log4j-layout-gelf >> log4j-layout-jackson >> log4j-layout-jackson-json >> log4j-layout-jackson-xml >> log4j-layout-jackson-yaml >> log4j-layout-template-json >> >> *logging-log4j2-osgi* >> log4j-osgi >> >> *logging-log4j2-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 the log4j-samples module and, if necessary, moving >> Flume-related parts to the log4j-flume-ng. >> >> *The problem with multiple repositories* >> >> I made this proposal in June 2021. Since then the more my familiarity with >> the website and manual generation increased, the less I became inclined to >> move forward. I am not much concerned about the increased release labor the >> Ralph has mentioned – a majority of these repos will hardly get an update >> to warrant a release. Though the fact that current website generation >> depends on the presence of these modules to be in the same repository and >> with multiple repositories, the manual and source codes will be in >> different repositories... These concern me a lot. I think, the steps to >> overhaul the project structure should better be in the following order: >> >> 1. Replace `site` phase (`site` phase won't be needed anymore. Website >> will independently be generated in a single step via JBake.) >> 2. Rewrite the manual >> 3. Migrate to a multi-repo structure (Each repo will have its own >> website and manual, ala Maven. Here the code in steps 1 and 2 will be >> reused.) >> >> >> >> On Wed, Apr 27, 2022 at 1:35 PM Ralph Goers <[email protected]> >> wrote: >> >>> I wouldn’t necessarily want to penalize them. At the same time, I don’t >>> think we want a ton of extra repos each of which needs its own release. >>> >>> Ralph >>> >>>> On Apr 27, 2022, at 12:26 PM, Piotr P. Karwasz <[email protected]> >>> wrote: >>>> >>>> Hello, >>>> >>>> On Wed, 27 Apr 2022 at 11:33, Volkan Yazıcı <[email protected]> wrote: >>>> >>>>> +1 with moving Cassandra et al. to their own repo >>>>> >>>> >>>> I agree: Cassandra's tests were one of the most common reasons for >>> failing >>>> CI. >>>> Maybe it could share a repository with other database appenders. >>>> >>>> Piotr >>> >>>
