[jwt-dev] Good dev practices : About allowing to disable JWT default fea

[Marc Dutoo <marc.dutoo@xxxxxxxxxxx>]

Hi all

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.

Ex. :
[Bug 257195] Disable overview page 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=257195
[Bug 256134] make original views deactivatable 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256134

Here are a few thoughts about how best to do it.


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 ?

Regards,
Marc