-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TEST to look at Gh build vs tip #7247
base: master
Are you sure you want to change the base?
Conversation
Added some logging.
Removed explicit System.exit(0) in Main. It allows to enable "slowtest" that generates and compares XMLs. Marked SystemExitInterceptor as deprecated and removal=true. Since Java does not offer any alternative, we have to find a better solution. P.S. NSIS is planned to be removed to use jpackage only.
…s StackTrace to determine the logger name. This is expensive and replaced with an explicit logger creation.
Please wait (as usual, I cannot tell until when) and don't merge this PR |
…methods that return null. In some cases, the null reference/result was not checked, but the code never failed, because it was not executed. There were no tests, that is why it was difficult to check, whether the refactoring was right :(
Update gh_build
1. Corrected the typo in special properties (light crossbow); 2. Corrected maxdex for MAXDEX bonus;
Yeah I assume we won't merge this PR, I figured it was just the easiest way to look at a diff and see if we could spot anything. |
# Conflicts: # data/pathfinder/paizo/roleplaying_game/core_rulebook/cr_equip_arms_armor.lst
Super interesting those tests fail for you but not for me locally! |
If you use your version/branch, but not mine, I bet you have this PR: #6975 |
OK, so just a data fix required then? |
…e the difference between "golden" and generated files). Trimmed lines in base.xml and base-xml.ftl template.
Corrected pf_Rogue.xml result: +1 reflex comes from Halfling Luch and +3 from his Cloak.
Not only:
|
…actions" Created a "graceful exit" object + interceptor. It is supposed to replace System.Exit calls in different parts of the project; Updated reporting.gradle by increasing versions of some dependencies; Removed a DM_EXIT rule from spotbugs -> the calls of System.Exit must be replaced with GracefulExit. The decision to create a custom interceptor was taken based on the discussion from Reddit: https://www.reddit.com/r/java/comments/1fpxmfp/jep_486_permanently_disable_the_security_manager/
Two commits above this comment are related to #7079. Security manager is mostly used to intercept System.exit calls; I hope, you will like it. |
Looks like it all passed! Shall we take out of Draft? |
It is unfinished. Do you insist? I need:
If you don’t need release builds for windows for now. I would implement my PR simply to have indicators that tests are green. Are you sure? Because I am not. You can actually merge it, but I only if you plan to work with the new codebase. E.g., continue improving GH actions. If not, I would keep it for a while draft. |
… DSL has been deprecated."
Replaced few System.exit with GracefulExit.exit calls. Refactored few methods to satisfy SonarQube warnings.
Refactored CommandLineArguments and its test. Increased the code coverage.
The commit 59833c5 addresses the issue #7079. We don't use SecurityManager directly (maybe its exceptions are still thrown here and there), but I have created a custom interceptor, called pcgen.util.ExitInterceptor. It is used in several test-classes. I don't know, if I should move my three "exit"-related classes/interfaces into a nested package (just to reduce litter in utils package). If you think, it will be a good idea, I will do this. Something like: "pcgen.util.exit". Thank you all. |
Thanks. I actually have some time today, so yes, I'll take a look. It'll be a couple hours from now, most likely. Since intercepting System.exit() is a no-no, I'm very curious to see how you did it! |
I don’t intercept it. I have got rid of it. There is only one place, where I allow it - GracefulExit 😄 |
@Vest Will happily wait until you're done, thanks for tackling this! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, big changeset. 🙂 A lot changes not directly related to GracefulExit
, but I mostly skimmed those.
I like the idea of using GE as a front-end on System.exit()
.
It all looks good to me!
int bonus = (load == Load.MEDIUM) ? 2 : (load == Load.HEAVY) ? 1 : (load == Load.OVERLOAD) ? 0 : statBonus; | ||
int bonus = switch (load) | ||
{ | ||
case MEDIUM -> 3; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be '2' instead of '3'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -98,40 +96,35 @@ public static String readFromURI(URI uri) throws PersistenceLayerException | |||
"The file %s uses UTF-8-BOM encoding. LST files must be UTF-8".formatted(uri)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Error message should be in a properties file...
Also, at a higher level, a file that starts with a UTF-8-BOM actually is a UTF-8 file, so this whole area might need reworking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope.
I don't honestly know what to deal with the error here. I have explained you that we had Apache Commons something (maybe String commons, I don't remember exactly) to work with BOM-files. I wanted to optimize the build, and I was trying to get rid of dependencies that are not that important.
When I analyzed all LST files, I found out that we had BOM in (maybe) 10 files, not more. It was easier for me to remove BOM and write code that fails/warns the user, if he gives an unsupported file.
LegacyKing was the first one (we don't have many data-contributors), who stepped this mine first. He was disappointed with the error, and I had to write this code just for him.
My thoughts are to add a Gradle task to go through all LST (or DATA) files and scan for BOM. Either convert them to non-BOM, or fail the build or whatever.
If I don't throw an error, a wrong LST will be pushed to the repo (I don't want this). If I throw an error, probably this build will fail and somebody else will be unhappy. Maybe I should convert LST files silently, but Karianna didn't like when "gradle test" modified .properties files even when nothing was changed. Maybe I'd better write an integration test that will fail, and after this PR is ready we will be able to see in the pull request, who is trying to break the build. Maybe I will also add a task such as "checkLst" to Gradle, so it will convert broken files to good ones. And in the test exception, I will write something like "BOM detected. Test failed. Use gradle checkLst to repair".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like you've got it under control. I wasn't aware of the backstory. 👍
ShowMessageDelegate.showMessageDialog("Preferences are currently set to NOT allow\nloading of " | ||
+ "sources from web links.\n" + uri + " is a web link", Constants.APPLICATION_NAME, | ||
MessageType.ERROR); | ||
+ "sources from web links.\n" + uri + " is a web link", Constants.APPLICATION_NAME, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another properties file template string...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
Moved a GUI-error message to the localization file. Formatted error messages
No description provided.