On 1/29/19 2:44 AM, Severin Gehwolf wrote:
Right, thanks! In fact, I've come up with something similar. Here is a patch which moves resource files for jlink plugins into their own properties files: http://cr.openjdk.java.net/~sgehwolf/webrevs/jlink-plugins-resources/01/webrev/ It's not super clean as there is still this weird plugin.opt.<name> artifact which has to do with TaskHelper and it's use of PluginOption, but I wanted to keep the patch as minimal as possible. Following this model, having platform specific plugins should be easier. Would this be something acceptable upstream? If so, I'll file an enhancement bug and an official RFR.
Thanks for doing this. Yes this should be a separate RFE. I think each plugin should have its own ResourceBundle instance as jlink should use the Plugin API to get the description, arguments etc for the output of --list-plugins. It does not need to maintain plugin to ResourceBundle map. It may involve more cleanup that I will have to look at the current implementation to give any suggestion. I think your patch does not necessarily depend on this refactoring and it makes sense to do this RFE separately and get the strip native debug symbol plugin in first.
I've tested this with tools/jlink/ and jdk/modules tests. Then the patch for the native debug strip plugin would become this: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796-wip/02/webrev/index.html Is this going into the right direction?
Looks reasonable. I will review it and send feedback. W.r.t. plugin resources, I suggest to have this plugin to maintain its own ResourceBundle and format its own message so that this can proceed independently with the existing plugin resource refactoring work. PluginsResourceBundle methods are convenient methods which this new plugin does not have to use it. Mandy
