RFR: Move jlink plugin resources into their own files

[Mandy Chung]

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