I would be comfortable with this if it is moved to its own repo and released first, then removed from the Log4J repo. I am not comfortable with “we can do it someday if we want to” unless we are dropping support for it.
Ralph > On Mar 20, 2023, at 3:36 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > [TLDR: Piotr and I propose moving `log4j-jmx-gui` to its own repository to > ease Java 9+ migration for `2.x`, objections?] > > In the `2.x` branch, AFAIK, `log4j-jmx-gui` is the only module that has a > Java 8 requirement, i.e., `jconsole.jar`. Piotr and I have been trying to > come up with ways to make `2.x` use a Java 9+ compiler (be it 11 or 17), > though every solution we have come up with has certain limitations due to > this `jconsole.jar` requirement. I want to propose moving `log4j-jmx-gui` > to its own repository. > > For one, we _can_ simply remove it from `2.x` for the time being and > postpone the new repository bootstrapping until there is a need to make a > change to `log4j-jmx-gui`. (Please note that I mention this for its > implementation convenience, not as a requirement.) > > Second, we _might_ break some users' workflow. Once the module is moved to > its own repository, it will have a separate release lifecycle, hence, we > should ideally remove it from `log4j-bom`. Users who run `log4j-jmx-gui` > through the dependency provided by `log4j-bom` will have a problem. Imagine > we release `log4j-bom` 2.21.0 that doesn't ship a `log4j-jmx-gui` > dependency. Piotr and I think that probably almost all `log4j-jmx-gui` > users provide an explicit version, hence our inclination for this breaking > change. > > Objections?
