I support the idea of removing `log4j-flume-ng` from `main` and figuring out a resolution later. I think it is too early to decide on how to further proceed with `log4j-flume-ng`; moving to a separate repository, merging it back to `main`, etc. The important thing is, we can always add it back to `main`.
On a similar matter, I am inclined to move `log4j-flume-ng` (in `2.x`) to a separate repository. It accounts for 10% of the build time. It is a very stable product with a happy user base. There is no need to keep its release cadence chained to `2.x`. On Thu, Aug 29, 2024 at 2:12 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi all, > > The `log4j-flume-ng` module _de facto_ contains 3 different appenders: > > * an Avro appender, that only depends on Avro and Avro IPC. Since it > only communicates with Flume via network, it doesn't need to even > depend on Flume, it just needs to use the same protocol. > * a Persistent appender, which works the same way as Avro appender, > but stores the messages to a local database first. It has an > additional dependency on `je` (a mostly unmaintained implementation of > BerkeleyDB). > * an Embedded appender, which is the only one that actually depends on > Flume. > > It also contains an undocumented (and untested) `Log4jEventSource` > plugin for Flume. > > The use of optional dependencies is not very JPMS friendly and we > probably would need to split it into 3 modules. To prevent delays in > releasing 3.0.0 I would propose to: > > * either move the `log4j-flume-ng` module to a separate repo and > release version `3.0.0` together with the next Flume release. > * or move it from the `main` branch to a different branch that will be > merged, when the module is ready. > > What do you think? > > Piotr >
