[platform-update-dev] Multiple features containing same plugin?

[Mark_Melvin@xxxxxxxx]

I have a quesiton about including the
same plugin in more than one feature, and what is the expected behaviour.

Currently, I have structured some of
my features using "nested features" to:

a) Reduce the number of top-level features
visible in the update site dialog (simplifying the update procedure)
b) Provide some logical structure to
my features
c) Feature dependencies to deploy my
common plugins seems cleaner than including the same (common) plugins in
multiple features

What I mean by #3 is, say I have 4 "leaf"
features - "Feature 1", "Feature 2", "Feature
3" and "Feature 4", which all include plugins from "Common
Feature 1", and also, "Feature 1" and "Feature 2"
contain some common plugins included in "Common Feature 2" and
"Feature 3" and "Feature 4" contain common plugins
from "Common Feature 3".  Since "Common Feature 2"
and "Common Feature 3" contain plugins that are not really functional
without "Common Feature 1", and additionally are useless with
the leaf features (1, 2, 3, and 4) that require them, but *also* contain
distinct stuff that have install handlers that do unique things preventing
them from being lumped into "Common Feature 1"...OK this is getting
very confusing.  Let's just day I have the following structure for
good reasons:


Common Feature 1
   |
   |
   + -Common Feature 2 (nested in Common
Feature 1)
   |   |
   |   +-Plugin C
   |   +-Plugin D
   |
   + -Common Feature 3 (nested in Common
Feature 1)
   |   |
   |   +-Plugin E
   |   +-Plugin F
   |
   +-Plugin A
   +-Plugin B


Feature 1
  Requires
      +-Common Feature 1
      +-Common Feature 2

Feature 2
  Requires
      +-Common Feature 1
      +-Common Feature 2

Feature 3
  Requires
      +-Common Feature 1
      +-Common Feature 3

Feature 4
  Requires
      +-Common Feature 1
      +-Common Feature 3

While nested features are a nice solution
for our particular situation, there are a couple of active bugs against
them and they cause problems.   In particular, update validation does
not traverse nested plugins (https://bugs.eclipse.org/bugs/show_bug.cgi?id=88464),
so specific versioning cannot be done on updates, and more limiting is
the fact that our installer fails when run from a UNC path due to nested
features and UNC paths not working properly (perhaps related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=90595)?

So, as I see it I have 2 options:

1. Make all of my features top-level, and just live with the mass of top-level features, relying on the platform update mechanism to guide the user through installing dependencies properly
2. Take the common plugins (C, D, E, and F from above)  and include them in the leaf plugins, completely removing the nested features.

Option 2 seems cleaner, but I'm not
sure if the platform will support this.  For instance, if both "Feature
1" and "Feature 2" include "Plugin C", what happens
at install/update/uninstall time?  If I have both features installed,
and I then uninstall only one of them, will Plugin C be removed?  Also,
what happens if I release an update to PluginC?  Updating Plugin C
will mean that both Feature 1 and Feature 2 will have an update shown on
the update site, but the update will be a new version of Plugin C in both
cases.  If the user chooses to install the update to both features,
will the update be installed twice ( I assume that is OK)?  Also,
what if the user only installed "one" of the updates, so I now
have Feature 1 installed which references v1.0 of PluginC, and Feature
2 installed that references v1.1 of PluginC?  Will this break my whole
platform, because I know the plugin registry cannot handle more than one
active version of the same plugin.  Will Feature 1 automatically use
the 1.1 version, even though it says in the feature.xml that it includes
v1.0?

I'm a little confused as to which is
the best solution here.  It seems to me like I have gotten feature-happy
and it is hurting me, but honestly we have so many special products which
use common components I don't there is any other way I can simplify it.

Thanks,
Mark.
----------------------------------------------------------