Re: [platform-update-dev] Update Manager Installs - Forcing the Use of a

[Pat McCarthy <patmc@xxxxxxxxxx>]

Well - that could work - a use what
you have approach. 

That would mean that all additional
software is lumped in one place - and that itself might cause problems.

Assume Product Q and extensions R and
S (now that there is no difference between an Update Site and an Extension
Site.

So if I read you right:

d:\q_inst_dir\
        \eclipse
 (<- Product inst dir, which itself may have other extension sites)
         
      \features
         
      \plugins
        \other\...
        \extension_home
(<-target for extension installs)
         
      \features
         
              \q.placeholder.feature
         
      \plugins
         
              \q.placeholder.plugin


R and S would say that they have colocation-affinity
with q.placeholder.feature.

But, lets consider a couple of scenarios:
1) When R or S needs to install lots
of other stuff to support their tool (sometimes the feature/plugin portion
is just a small bit of what is required), they would not want to hide it
in the \extension_home area so it would be installed somewhere else. At
this point they would probably have a formal installer for the extension,
so we can say they don't use this placeholder technique.

2) If the user has multiple Eclipse-based
products installed (Q1, Q2), they may find that R or S was able to extend
multiple targets.  What to do then?  Download into one \extension_home
dir and then download again for the next product? (but again, maybe we
say they don't use this placeholder technique).

3) Same as 2), but from the extension's
viewpoint - which placeholder.feature to they identify in their feature
to be installed? Q1 or Q2? (Or do they avoid the issue by deciding not
to use the placeholder technique).

4) Say I download and config both R
and S using Q1.placeholder.feature. But I also need R over in Q2.  I
can't use the Software Updates > Manage Configuration dialog to do this
by adding \extension_home as a linked site as I'd get both R and S and
then need to go disable one of them, but the R feature could not target
both Q1 and Q2.

These problems might cause a bit of
trouble.  There still might be room for products to create this structure
to support their own after-the-install add-ons, or if they want to organize
their own code into \extension_home, or just offer this as a target for
feature/plug-in sets that only plan on extending the one tool.

Guess I'd still like to understand what
it would take in feature.xml to get the Update Manager installer, when
loading from an update site, to choose a default location other than the
product's install tree. 
We could add some attribute to the feature
spec that says install in location XYZ, where the file system location
of XYZ is platform specific (C:\Program Files\XYZ on Windows for example).
 This would have to be either supported when only defined for a root
feature (included features follow parent) or it would have to be defined
in every feature (a pain).

Or maybe the solution is do very little
- just change the default.  Assuming we'd not prevent the user from
changing the target directory, we can't stop them from putting it in the
'wrong' place.  Maybe all we really need is a target site on the Install
wizard page that chooses a new target site based on the feature id and
some default location that is not the current product's Eclipse dir.  We
could use a wizard page that includes a new toggle that is selected by
default. The toggle would say "Create new target install site"
- where the location is based on a platform default.  Changing the
default target location to another location should be possible while the
toggle is selected, but if the toggle is not selected then all they do
is choose an existing install site. This reverses the current flow where
an existing site is selected by default.

Or - a less specific statement in the
feature.xml might just say install-site="public|private" - public
is a rule for any site will do (new or existing) while private is a rule
that says a new or empty install site must be used (Default public).  If
this could be said once for a feature and applied to any included feature....
it might work too.

Of course all of this may be more than
what some want or think they need. If you want to cram all your plug-ins
into one site I guess you should be allowed.  I'm trying to consider
the case for how to best manage a common base that is provided by one vendor
but extended by others (formal ISVs and other feature/plugin sets that
might be discovered by the customer).  In this scenario we don't want
the additional code to get deleted when the existing product install is
reworked (an uninstall/reinstall form of update for example).



Pat McCarthy