| Plugin States Within Current Eclipse (mail with Jeff) [message #24642] |
Wed, 14 May 2003 01:08 |
 Keith Kimball
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
>> Keith's Response
1. If we want to match Pascal's state diagram, the
getEnabled and setEnabled functions exported by
PluginDescriptorModel should be called getResolved
and setResolved. The enabled flag is used by the
RegisryResolver to indicated whether or not the
plugin was resolved into the registry. However,
since the functions are used in the pde, I do not plan
on changing the names. At this level, this is the only
plugin state maintained, the author was thinking
in terms of disabling unresolved plugins, and it is
not that confusing.
2. The more interesting states are those in the PluginDescriptor
which is internal to the runtime, only relevant for RESOLVED
plugins, and transitions occur during Eclipse exeuction. The
states (currently maintained as a set of booleans) seem to be:
- Inactive
- ActivePending
- Deactivated (changing name to something like ActivationFailure).
- Active
Regarding the intent of the current isDeactivated(). This
is something I discovered rather than invented. The state
results when an exception occurs during plugin activation.
For example, during class loading, running of the plugin
constructor, or running of the pluign start method. The
platform remembers this state so it can avoid repeated
activation failures.
>> Mail from Jeff to Keith
Overall, I suggest you deprecate old API for now. This
minimizes breakage (maximizing function) and expresses
your intent.
re: get/setEnabled. Its been a while since I looked at these.
I suspect that the API should just have isResolved(), isEnabled, \
isConfigured,...
Disabling, deconfiguring a plugin should be an operation on the
PlatformConfiguration or some such.
re isDeactivated(). What is the intention here? That is, what error
state are you thinking of? I could imagine wanting to know if a currently
!isActivated() plugin has ever been isActivated(). Perhaps
hasBeenActivated() or wasActivated()? Those in combination with
isActivated() should cover all states.
Jeff
>> Mail From Keith To Jeff
Jeff,
How much flexibility do we have at refactoring interfaces? The two
places I would like to change names are:
org.eclipse.core.runtime.model.PluginDescriptionModel.
I would like to change the {get,set}Enabled to {get,set}Resolved
to match Pascal's state diagram. The problem with this is that an
internal PDE routine references it. I'm hoping to change the name
prior to checkin but ...
org.eclipse.core.internal.plugin.PluginDescriptor.
I would like to change isPluginDeactivated to
isPluginDeactivatedDueToError. This is not used outside of the
runtime and I suspect this is ok.
Keith
|
|
|
Powered by
FUDForum. Page generated in 0.45730 seconds
] 
Search
Help
Register
Login
Home
