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

[Paul Sandoz]

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