Sorry, it occurs to me that you may be implying that stuff written for 3.x should also work in 2.x. That would be a bit strange from a semantic versioning standpoint. In addition, because we have moved the plugin support to its own module in 3.x stuff written for it can’t compile in 2.x. However, we preserved enough of the 2.x plugin support that stuff compiled for 2.x will work in 3.x. Moving the plugin support to its own module in 2.x would also be a non-starter for me. This kind of stuff is exactly why we are changing the major version number. You don’t do that in a minor version.
Ralph > On Apr 18, 2022, at 11:07 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Gary, that really doesn’t say anything. 2.x and 3.x are already designed to > be able to coexist. > > Ralph > >> On Apr 18, 2022, at 10:50 PM, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> For my 2c, the better internals are not going to motivate the majority of >> users to update to 3.0, features are. It might be different for plugin >> authors, but how many of those are there? My guess is a minuscule amount. I >> agree that 2.x should live for a long long time, and should be able to >> coexist with 1.x and 3.x. >> >> Gary >> >> Gary >> >> On Mon, Apr 18, 2022, 14:56 Piotr P. Karwasz <piotr.karw...@gmail.com> >> wrote: >> >>> Hi Volcan, >>> >>> On Sun, 17 Apr 2022 at 22:42, Volkan Yazıcı <vol...@yazi.ci> wrote: >>> >>>> 1. I was working on LOG4J2-3082 (support external serializers, e.g., >>>> Jackson, in JTL) and there I needed `@RequiredClass`. Ralph already >>>> implemented this in `master`, I just need to copy it to `release-2.x`, >>>> after all it is just a `@ConstraintValidator`, right? Right... But it >>>> simply won't work. Because JTL, as `PatternLayout`, uses >>>> `PluginManager` to >>>> load plugins and that doesn't support `@ConstraintValidator` et al.?! >>>> I've >>>> discussed this with Matt and we came to the conclusion that porting >>> the >>>> new >>>> plugin infra from 3.x to 2.x is easier compared to fixing the problem >>> in >>>> 2.x. >>>> >>> >>> Maybe this can be solved in other ways. For example we could have a: >>> 1. `SerializerFactory` with multiple implementations each one in a separate >>> module, >>> 2. You use the `ServiceLoaderUtil` to find an implementation or you use the >>> internal one if there are none. >>> >>> I think that the dependency injector is a feature that should stay in 3.0 >>> to motivate people to move from 2.x. >>> >>> Piotr >>> >