[news.eclipse.technology.equinox] Re: Plugins - singletons or not?

["Kevin" <kduffey@xxxxxxxxxxxxx>]

Jeff,

I would go as far as stating that in order to allow your plugin and any
dependents to be properly unloaded/reloaded, a developer MUST follow the
guidelines or own up to the problems that may occur when his/her plugin is
running along side plugins that do abide by the guidelines. I don't see any
reason why plugin developers can't follow the guidelines, what's the point
of developing a plugin for a framework and its engine if the plugin is a
renegade.

Assuming that the result of this project is an engine that can be used for
other UI based applications (outside of Eclipse), i'd say that each person
using the engine in their application should specify a best practices
guidelines for plugin developers.


"Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx> wrote in message
news:b6abss$4c3$1@xxxxxxxxxxxxxxxx
>
> "Mel Martinez" <melm@xxxxxxxxxx> wrote in message
> news:b6a99d$28t$1@xxxxxxxxxxxxxxxx
> > Jeff McAffer wrote:
> >
> > > Yes.  I am a little unclear about the need to remove references to
> classes.
> > > While this may be a good thing in general, clearly plugins are going
to
> > > reference classes from other plugins.  Clearing up this one case does
> not
> > > solve the problem.  So what am I missing here?  Are you proposing that
> all
> > > cross plugin class references use some sort of service registry
> mechanism?
> > > As a point of interest, how does that work for subclassing,
> implementing,
> > > casting etc style relationships?
> > >
> >
> > Plugin subclasses are a special case compared to other classes in the
> > plugin packages because they provide 1)based on the lifecycle, the
> > Plugin subclass provides a logical starting point of initialization for
> > the rest of the plugin and 2) a platform-defined API for accessing a
> > variety of plugin-specific services (for example access to
> > Plugin.getPluginPreferences() provides a very plugin-specific service)
> > without need for visibility of the particular plugin's classes.
> >
> > In other words, (1) provides reason for subclassing the Plugin class and
> > 2) shows that cross-plugin utilization can happen without specific class
> > visibility.
>
> Agreed.  Relating this back to the original topic, we should advise
against
> using MyPlugin.getDefault() and recommend Platform.getPlugin("myPlugin").
> Generalizing this, one of the tips and tricks for writing dynamic plugins
> should include "avoid references to classes from other plugins where
> alternatives exist or can be designed in".
>
> Do you have a common usecase for one plugin to reference another's generic
> plugin services (e.g., preference store) and have no references to any
> classes from the plugin.
>
> > Thus, a best practice for a component provider is (as Olivier has
> > mentioned repeatedly) to put the public interfaces and abstractions in
> > one 'B' plugin (which would tend to not get unloaded) and put
> > implementations in separate 'C' plugin(s) that can be unloaded.
> >
> > And a best practice for a component consumer 'A' is to 1) only compile
> > against the 'B' plugin's classes and 2) never retain stateful reference
> > to objects pulled from other plugins.
>
> right.  This is the service model.  It gives you finer granularity for
> talking about changes.  We can think of each plugin as one big service
that
> can change in various ways.  See the registry delta discussion.  It is
still
> possible to have finer granularity as complementary function.
>
> > > The <requires> elements tell you that if A requires B and B is
shutdown,
> > > replaced, ... A needs to do something.  The straightforward approach
is
> to
> > > shutdown and restart all the dependents (or the whole platform) in
these
> > > situations.
> >
> > Yeah, I think that the straightforward solution is that if A requires B,
> > and B exports any classes, the assumption must be that A requires class
> > visibility and must be shutdown as well.  That supports the current
> > model.  As an enhancement to the relationship, though, we could extend
> > the plugin.xml so that when A specifies that it <requires> B, it
> > optionally can specify that it listens for events which would allow it
> > to clean up.  In that case we would try to unload B without shutting A
> > down as well.
>
> The registry deltas allow for this information to be transmitted but
> currently there is no way to say that A should not be shut down.  Imagine
> that as a result of being told of B's shutdown, A could respond with "shut
> me down too" or "B?  what B?".  Default would be the former.  Smarter
> plugins could do the latter.
>
> Jeff
>
>