RFR 8160063: Provide a means to disable a plugin via the command line
mandy.chung at oracle.com
Thu Sep 15 16:50:10 UTC 2016
-—disable-plugin <plugin_name> can allow any plugin if present, regardless whether it’s auto-enabled or not. If the plugin is disabled, -—disable-plugin will just be nop.
Looking at Plugin.State::DISABLED:
<li>DISABLED: The plugin is not exposed in help and will be not called.</li>
It’s unclear this is needed. I guess this was defined to allow a plugin to handle the disable option like --generate-jli-classes=none. I don’t see when a plugin is added to jlink with DISABLED state.
We should revisit Plugin.State enum.
> On Sep 15, 2016, at 9:36 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> With "--disable <plugin_name>", user can pass any plugin name - even the
> plugins that are *not* auto-enabled. We may have to check and report.
> But, --disable-<plugin_name> options are added only for auto-enabled
> --disable-<non_auto_enabled_plugin> will automatically fail as
> "unsupported option".
> On 9/15/2016 9:57 PM, Paul Sandoz wrote:
>>> On 15 Sep 2016, at 09:06, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>> On Sep 15, 2016, at 8:26 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>> On 15/09/2016 07:31, Sundararajan Athijegannathan wrote:
>>>>> Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063
>>>>> * Adding --disable-<plugin_name> option for any plugin that is auto-enabled.
>>>> Should this be --disable-plugin <plugin-name> rather than synthesizing an option?
>>> jlink --disable-plugin generate-jli-classes does read better. The option is more obvious.
>>> The other way to look at this option is an option provided by each plugin like --generate-jli-classes=none.
>>> Given that the plugin name is arbitrary, "--disable-plugin <plugin-name>” would be more obvious and I have no issue to go with that.
>> Yes, that is better. I am guessing the "-disable-<plugin_name>” approach was proposed to be consistent with the plugin configuration options, so perhaps that should also be reconsidered?
>>>> Also would I be correct to say anarchy such as `jlink --disable-generate-jli-classes --generate-jli-classes` would actually run the plugin? Related is whether it's warning or fatal when an unknown plugin is specified.
>>> Good question. --disable-generate-jli-classes removes the plugin from the map and so it won’t run. When an unknown plugin is specified, I suggest it should be fatal and I think that’s the current behavior.
>>> If both the option to disable and to enable are specified (in any order), fatal would be helpful such that the user is prompted to ask one thing not the other.
More information about the jigsaw-dev