Since we're geared more towards making JWT flexible enough for vendors
to extend it, the question of disabling default JWT features has
appeared several times.
1. The right question is not about "disabling" but rather about "making
optional". Likewise the solution is not to create an extension point
that disables it, but to create an extension point that allows to
externalize the default code in an optional plugin. Moreover if there
already exist a similar extension point, it should be reused so as to
unify and make consistent the whole architecture.
2. Required flexibility can be introduced at several architectural
levels that use various technical solutions. Common architectural levels
are :
* plugin level, using extension points ; typically gives flexibility
to the vendor, so he can choose a plugin feature to be part of its
release or not.
* application level, using preference entry ; gives flexibility to
the user, so he can customize its use of JWT.
* NB. An intermediary level between both could be externalized
properties.
3. A single feature may be made flexible at both levels if such
flexibility is useful 1. for the vendor at packaging time and 2. for the
user at use time. For instance, profile / aspect configuration files can
be both plugged in using an extension point (requires the vendor to
package it as a plugin) or / and put in a directory where it is
autodiscovered at startup (or specified in a preference page, but this
has not been done yet). However, the UI pertaining to such flexibility
through plugin is any kind of release-making tool and not the
PreferencePage UI (which in turn is the rather user-oriented
configuration UI) !
4. I'm wondering whether there is some common patterns or code about all
this to be shared / gathered in a framework... Thoughts ?