RFR: 5904: Merge org.openjdk.jmc.ui.celleditors with org.openjdk.jmc.rjmx.ui.celleditors [v4]

[Marcus Hirt]

On Fri, 20 Aug 2021 15:25:52 GMT, Jie Kang <jkang at openjdk.org> wrote:

>> Er, yeah I guess I was thinking more of a flow diagram, I have it backwards here.
>> 
>> The reason it  looks like most of the classes were in rjmx.ui anyways was because they use classes from rjmx. So if the classes are moved from rjmx.ui to jmc.ui, they'd still need access to those (specifically rjmx.services and subscription.internal), so we'd have to add a dependency on those to jmc.ui.
>
> Hm, okay. I took a step back and looked at the actual issue at hand.
> 
> I think it's more intended to migrate any cell editors from ooj.rjmx.ui to ooj.ui. The cell editors in ooj.rjmx.ui that have rjmx specific code (ie. import ooj.rjmx packages) should not be moved. (Should still be analyzed whether they can be modified and moved)
> 
> rjmx.ui is a specialized subset of ui for rjmx purposes, while ui is a general set for anybody to use (rjmx, flightrecorder, etc.). Why would we want to move things from ui to rjmx if they're not specialized for rjmx purposes? Especially as you note that there's already non-rjmx users of the things.

Here is some context for my comment. 

Right now you could very well deliver a build of JMC that is only a JMX console. All you'd have to do was to have a few of the features bundled together (core, mbeanbrowser, console, blabla and leave out what you don't want, e.g. leaving out the joverflow and jfr features). Similarly you could package a new tool that is only a JFR tool, used exclusively to open flight recording files, and nothing else.

By requiring rjmx.ui to have a dependency on flightrecorder.ui, the dependency waters get muddied. For building a tool that uses rjmx.ui, you now always need to drag in the entire flightrecorder ui.

-------------

PR: https://git.openjdk.java.net/jmc/pull/271