jmc
jmc copied to clipboard
7308: Move non-Eclipse dependant classes from org.openjdk.jmc.ui.common to org.openjdk.jmc.common
This PR addresses JMC-7308 [0], in which it would be helpful to have some of the classes currently in jmc.ui.common shipped in core.
There are a number of classes currently in jmc.ui.common that would be a great asset to the core distribution (and the third-party applications that consume jmc-core), and these classes could live in jmc.common.
It isn't as straightforward as moving all of the packages to core, as there are still classes in these jmc.ui.common packages that have dependencies on Eclipse or rjmx. Having said that, the ones listed below can be moved without much difficulty:
-
org.openjdk.jmc.ui.common.action (3) Executable, IActionProvider, IUserAction
-
org.openjdk.jmc.ui.common.jvm (5) Connectable, JVMArch, JVMCommandLineToolkit, JVMDescriptor, JVMType
-
org.openjdk.jmc.ui.common.resource (2) IImageResource, Resource
-
org.openjdk.jmc.ui.common.security (10) ActionNotGrantedException, CredentialsNotAvailableException, FailedToSaveException, ICredentials, InMemoryCredentials, ISecurityManager, PersistentCredentials, SecurlyStoredByteArray, SecurityException, SecurityManagerFactory
-
org.opendjk.jmc.ui.common.tree (3) IArray, IChild, IParent
-
org.openjdk.jmc.ui.common.util (4) Environment, Filename, ICopyable, IObservable
-
org.openjdk.jmc.ui.common.xydata (5) DataSeries, DefautlTimestampedData, DefaultXYData, ITimeStampedData, IXYData
[0] https://bugs.openjdk.java.net/browse/JMC-7308
Progress
- [x] Commit message must refer to an issue
- [ ] Change must be properly reviewed (1 review required, with at least 1 Committer)
Issue
- JMC-7308: Move non-Eclipse dependant classes from org.openjdk.jmc.ui.common to org.openjdk.jmc.common
Reviewers
- Brice Dutheil (@bric3 - Author) ⚠️ Review applies to acde37ac
Reviewing
Using git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jmc pull/300/head:pull/300
$ git checkout pull/300
Update a local copy of the PR:
$ git checkout pull/300
$ git pull https://git.openjdk.org/jmc pull/300/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 300
View PR using the GUI difftool:
$ git pr show -t 300
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jmc/pull/300.diff
:wave: Welcome back aptmac! A progress list of the required criteria for merging this PR into master
will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.
Webrevs
- 10: Full - Incremental (e2c3059f)
- 09: Full - Incremental (9010a683)
- 08: Full - Incremental (2d39bd98)
- 07: Full - Incremental (436421a2)
- 06: Full - Incremental (f86c034e)
- 05: Full (2536c4a7)
- 04: Full - Incremental (e54a0934)
- 03: Full (c06f3752)
- 02: Full (a99a9c1b)
- 01: Full (69aeed33)
- 00: Full (acde37ac)
Similar to my other PR (https://github.com/openjdk/jmc/pull/299), this has been rebased onto the current master branch for consideration in JMC 9.
Could you enable Github Actions on your repo and merge with master?
@aptmac Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.
Could you enable Github Actions on your repo and merge with master?
That sounds like a good idea to me, would you happen to know how to enable it? I tried looking at the documentation [0] and it's wanting me to use the Actions tab, which isn't visible on this repo (for me at least).
[0] https://docs.github.com/en/actions/managing-workflow-runs/disabling-and-enabling-a-workflow#enabling-a-workflow
Could you enable Github Actions on your repo and merge with master?
That sounds like a good idea to me, would you happen to know how to enable it? I tried looking at the documentation [0] and it's wanting me to use the Actions tab, which isn't visible on this repo (for me at least).
[0] https://docs.github.com/en/actions/managing-workflow-runs/disabling-and-enabling-a-workflow#enabling-a-workflow
You have to go to the Actions tab of your personal fork (https://github.com/aptmac/jmc). There you should be prompted with a dialog to activate it.
@aptmac this pull request can not be integrated into master
due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:
git checkout PR-7308
git fetch https://git.openjdk.org/jmc.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push
Just doing some cleanup, still have to update the license headers to 2023 and figure out GH actions.
Edit 1: looks like the actions are running, nice Edit 2: have a couple of issues to work out, will fix that up soon
It's been a while since I've opened this PR and updated it. For context, this PR was originally opened in 2021 and paired with https://github.com/openjdk/jmc/pull/299 (which is now succeeded by https://github.com/openjdk/jmc/pull/469), in an attempt to bring classes into core from application.
The end goal is to get the rjmx functionality into core for easier consumption by applications. This work is tracked in the issue: https://bugs.openjdk.org/browse/JMC-7069
I've updated and got it running locally, I'll be going through the review comments on https://github.com/openjdk/jmc/pull/299 as they might apply here since both PRs were opened at the same time.
tl;dr Apart from classes in
.action
,.resource
,.tree
,.util.ICopyable
,.util.IObservable
. This looks like nice change in particular for classes likeJVMArch
.
That's fair, I can hold off on those classes for now. They're intertwined with the rjmx classes so I was thinking ahead to the issues related to bringing rjmx into core: JMC-6627 [0] and JMC-7069 [1]. These could instead be moved/migrated/altered when it comes time for that work to go in.
[0] https://bugs.openjdk.org/browse/JMC-6627 [1] https://bugs.openjdk.org/browse/JMC-7069
@aptmac This change now passes all automated pre-integration checks.
ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.
After integration, the commit message for the final commit will be:
7308: Move non-Eclipse dependant classes from org.openjdk.jmc.ui.common to org.openjdk.jmc.common
Reviewed-by: bdutheil, clanger
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.
At the time when this comment was updated there had been 3 new commits pushed to the master
branch:
- 80ab189bd5ba65123d3b29754bbba5d3a8b314c5: 8070: Move to JDK 17 leftovers
- 200d0f8fffc4a646c28c2d570f23e0ac48eff117: 7457: Unnecessary imports should fail the build
- 3c7056066838e34e1a8ed1fd2071a652595197e1: 8050: JMC Automated Analysis should improve the messages when ignoring to evaluate some rules.
Please see this link for an up-to-date comparison between the source branch of this pull request and the master
branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
➡️ To integrate this PR with the above commit message to the master
branch, type /integrate in a new comment.
/integrate
Going to push as commit ff2fba4492009419761e85ae95bfcfd0ced82f60.
Since your change was applied there have been 3 commits pushed to the master
branch:
- 80ab189bd5ba65123d3b29754bbba5d3a8b314c5: 8070: Move to JDK 17 leftovers
- 200d0f8fffc4a646c28c2d570f23e0ac48eff117: 7457: Unnecessary imports should fail the build
- 3c7056066838e34e1a8ed1fd2071a652595197e1: 8050: JMC Automated Analysis should improve the messages when ignoring to evaluate some rules.
Your commit was automatically rebased without conflicts.
@aptmac Pushed as commit ff2fba4492009419761e85ae95bfcfd0ced82f60.
:bulb: You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.