-—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.athijegannat...@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.ch...@oracle.com> wrote: >>> >>> >>>> On Sep 15, 2016, at 8:26 AM, Alan Bateman <alan.bate...@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 >>> >
