JDK-8160063 : Provide a means to disable a plugin via the command line
Type:Enhancement
Component:tools
Sub-Component:jlink
Affected Version:9
Priority:P3
Status:Closed
Resolution:Fixed
Submitted:2016-06-22
Updated:2016-11-08
Resolved:2016-11-03
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
There is currently no way to disable plugins that are AUTO_ENABLED. For example, suppose we want to disable the generate-jli-classes plugin so that it doesn't generate classes at link time.
Comments
I think it's better to provide a consistent mechanism to disable any plugin. Otherwise, a plugin may choose to use "none", "off", "disable" or even does not allow to be disabled (intentionally or unintentionally).
I agree that SystemModuleDescriptorPlugin should not be disabled but the runtime supports without such optimization.
On the other hand, I think SystemModuleDescriptorPlugin should also be hidden from the --list-plugins. At one point there was a way to hide a plugin from the --list-plugins output. Plugin::showHelp or some way a plugin can configure to hide from --list-plugins output.
14-09-2016
I attempted --disable-<plugin_name> idea as that is clean and easy to use.
But, currently only two plugins are auto-enabled.
1) GenerateJLIClassesPlugin
2) SystemModuleDescriptorPlugin
I think we don't want SystemModuleDescriptorPlugin to be disabled at all [ as we generate crucial optimization info like concealed packages for example). And it turns out that GenerateJLIClassesPlugin already provides facility to turn off generation:
jlink --generate-jli-classes=none
disables it. That is documented in that plugin's description as well [This is equivalent to Mandy's suggestion of "off"]
I think it is safer to leave the decisions to plugin (1) whether user can disable or not and (2) if can be disabled how to disable and so on.
14-09-2016
Please re-open this issue if my last comment is not acceptable or if there is better suggestion.
14-09-2016
One option is to provide a jlink option to disable the named plugins.
a) --disable-plugins <plugin-name>[,<plugin-name>]
jlink --disable-plugins generate-jli-classes
b) --disable-<plugin-name>
jlink --disable-generate-jli-classes
For each plugin, jlink automatically adds `--<plugin_name>[=<arguments>]` option with an optional arguments. I like (b) symmetric with the option to configure the plugin:
`--<plugin_name>[=<arguments>]`
`--disable-<plugin-name>`
jlink can parse CLI options and invoke the plugins that are not disabled.
Another alternative could be an option to the plugin e.g.
jlink --generate-jli-classes=off
This will rely on the plugin implementation to handle that (the arguments are currently passed to the Plugin::configure method). `off` was the option in an early jlink prototype.