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