RFR 8160063: Provide a means to disable a plugin via the command line

[Mandy Chung]

-—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. 

Mandy


> 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
> plugins.
> 
> --disable-<non_auto_enabled_plugin> will automatically fail as
> "unsupported option".
> 
> -Sundar
> 
> 
> 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?
>> 
>> Paul.
>> 
>>>> 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.
>>> 
>>> Mandy
>>> 
>