[platform-update-dev] Re: Filters for eUpdate

[Mel Martinez <melm@xxxxxxxxxx>]

This is a tricky issue.  One can address it partly at the feature
installation level.  One can specify <requires> dependencies in the
feature.xml to make sure the 'full set' of needed platform plugins are
present.  I realize that that does not always go far enough.  By using a
custom installhandler, you can also instrument the act of downloading &
installing your feature to do prerequisite checks that are outside the
bounds of normal eclipse dependency checks.   The problem there, of course,
is that the feature itself has to be downloaded and the installhandler has
to be invoked just to do tests, only to find out the feature can't be fully
installed for whatever reason.   For performance reasons, declarative
dependency resolution is always preferable, but not always possible.

  ----- Original Message -----
  From: James D Miles
  To: platform-update-dev@xxxxxxxxxxx
  Sent: Tuesday, November 08, 2005 6:25 PM
  Subject: [platform-update-dev] Filters for eUpdate


  It is not clear to me that we have adequate filters for features.
  We have
  os = {win32, linux, aix, solaris, hpux, qnx, macosx, unknown}
  arch = {x86, PA_RISC, ppc, sparc, x86-64, ARCH_X86_64, ia64, ia64-32}
  ws = {win32, motif, gtk, photon, carbon, unknown}

  What would be the preferred way to prevent eUpdate from attempting to
load a feature that expects a full blown platform. Chances are good that
the required features or plugins would not be satisfied but that will give
an error. Shouldn't we have a filter to handle this?