Splitting the repos might be effectively the same as donating them to others, so I’m fine with either approach.
— Matt Sicker > On Jun 10, 2022, at 10:43, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > It has been my plan to create a PR for Spring to move the Spring Boot > support there. They already provide support for Log4j2, it is just deficient. > > I have no plans to move the Flume Appender to the Flume project. > However, I do plan to move it to its own Log4j repo in 3.x. I would > suggest the same thing happen to many of these other components. > > Other projects taking ownership of them is very unlikely to happen. > > Ralph > > >> On Jun 10, 2022, at 5:51 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: >> >> Would any of those projects be willing to maintain a Log4j-related >> component that was born and raised in the Log4j land? I think that is >> pretty wishful thinking, though feel free to give it a try. I support any >> initiative that would lower the maintenance burden without hindering the >> development of Log4j. Does anybody volunteer to raise this subject in the >> associated mailing lists? >> >> I am not concerned about the `log4j-core` API stability, I think we do a >> good job there. >> >>> ... if the upstream projects don't want them, then those modules get >> EOL'd and removed for 3.x >> >> Umm... I don't think that is a nice way to treat our existing users. (Ralph >> would disagree anyway. In fact, I am surprised he hasn't reacted yet.) I >> would rather move these to separate repositories and maintain them there. >> For those interested in this route, please start another thread. For >> inspiration, see my earlier posts >> <https://lists.apache.org/thread/8rflqfctmpd79h11o78zkfymtn6g9sds>. >> >> On Tue, Jun 7, 2022 at 8:17 PM Matt Sicker <boa...@gmail.com> wrote: >> >>> Hey all, >>> >>> I was wondering if you'd all be on board for 3.x to try and move some >>> of our 3rd party integration plugins to their respective projects >>> rather than maintaining them here. For example, all the networked >>> appender plugins and other plugins that typically require a third >>> party client library or driver would be more appropriately located >>> with their respective dependencies. A concrete example would be moving >>> the Flume appender to Apache Flume once they're finished with 1.10.0 >>> which is under review right now. While we'd keep releasing this >>> appender in 2.x, come 3.x, we'd be able to point to the official Flume >>> plugin instead. The same idea could apply to numerous plugins such as: >>> >>> * Cassandra appender -> Apache Cassandra >>> * Flume appender -> Apache Flume >>> * JDBC/JPA appenders -> ? (Eclipse Jakarta perhaps?) >>> * JMS appender (could go to ActiveMQ or Jakarta) >>> * Kafka appender -> Apache Kafka >>> * MongoDB appenders -> MongoDB? >>> * CouchDB appenders -> Apache CouchDB >>> * SMTP appender -> makybe Jakarta? >>> * ZeroMQ appender -> ZeroMQ project? >>> * Spring integration stuff -> Spring project >>> * Liquibase binding -> Liquibase >>> >>> I imagine it makes some sense to continue publishing our -web and >>> -appserver modules as they're more specific to hooking log4j-core into >>> those things, but I'm open to other ideas there. >>> >>> For any plugins we're trying to move, if the upstream projects don't >>> want them, then those modules get EOL'd and removed for 3.x. >>> >
