Use RuboCop to clean up poms (9.4) - #8974
Conversation
Sorry, something went wrong.
|
I have provided .rubocop-pom.yml for future cleanup or auditing. Latest commit disables it in a couple of key places and makes a couple other small tweaks to get mvn deploy -Psnapshots to run (which should touch just about all pom.rb files). Tests are green. I have only enabled one additional cop: Style/StringHashKeys to clean up hashes and keyword argument calls that still used strings. Some of these strings were not naturally "symbolable" (e.g. "Automatic-Module-Name") but the consistent use of key: value format looks much cleaner. The other tweaks involved two changes:
|
Sorry, something went wrong.
* core/pom.rb: environmentVariables must be strings or we convert the underscore casing to camelCase and they don't work (I'm not sure why we do this). Disable StringHashKeys cop to avoid this. * core/pom.rb: default_compiler_configuration can be symbol keys but must be accessed using same. * lib/pom.rb: Revert to path-based reopening of ext builder class. Disable ClassAndModuleChildren cop as it is not safe here. See rubocop/rubocop#14476. * maven/pom.rb: map of submodules must not use symbol keys, because we do not autocoerce to String when calling the Maven `profile` method. Disable StringHashKeys here as well.
This turned out to be an unsafe correction by RuboCop, due to the difference in behavior from path-based module reopening versus nested module reopening. I've filed rubocop/rubocop#14476 and disabled that cop for the line in question (leaving it as a path). |
Sorry, something went wrong.
See jruby#8974 for the original exploration against the 9.4 branch and reasons for enabled and disabled cops and other changes.
Clean up all polyglot pom files using automated tools. These changes are highly unlikely to merge across branches, so we'll run this process against 9.4 and 10 separately.