[p2-dev] IU Visibility and Server-Side IU Filtering

["Mark Melvin" <Mark.Melvin@xxxxxxxxxx>]

Hi Everyone,

I am 95% of the way done prototyping with P2 and I have come to the
final piece of the puzzle in moving our product over from the old update
manager.  I was hoping to get an answer to my last fundamental set of
issues here on the dev list.

I would like to move to a P2-only solution, for obvious reasons.
However, one thing I am still struggling with is controlling the
visibility of what is shown in the UI when updating or installing new
features from a P2 repository.  I have two angles in which this is an
issue for us.

First of all, I am going to have a lot of "configuration" type features
whose sole purpose will be to install external (root-*ish*) files.  I
have basically got this working, complete with custom touchpoint actions
and metarequires clauses.  This will take the place of our install
handlers, which was preventing us from moving to P2 in the past.
However, I will have many features that I do not want exposed to the
user to install outside of their parent containing features.  I just
read Ian's post
(http://eclipsesource.com/blogs/2009/05/08/categorize-your-repository/)
on categories (which is great), but it seems there is still the checkbox
in the UI (Group Items By Category) that basically means "show me
everything anyway".  Nick Boldt responded with a site.xml trick that
worked in 3.4, but I am not sure it will work in 3.5 and I don't want to
go back to site.xml files (they are not used by P2 normally, right?).

After quite a bit of digging in the source I found the SDKPolicy and
IUViewQueryContext classes and this seems to be the ticket.  But this
led me to this wiki page:

http://wiki.eclipse.org/Equinox/p2/Adding_Self-Update_to_an_RCP_Applicat
ion

So now it looks like I need to write a bundle, some code, learn
declarative services, etc. etc.  Is it really this complicated?  Why
can't it be as simple as a flag or property in the metadata (like the
group and category properties) that can control this sort of thing?  The
site.xml was nice because if you did not list it in the site.xml, it was
never shown.


Which brings me to my next fundamental issue.  With the old update site
approach, we have a fairly large infrastructure built around customer
authentication on a "portal"-type website, where their credentials
(provided via standard HTTP authentication and some simple server-side
scripting to generate a site.xml on the fly) dictate exactly what
updates and products they have access to.  I'm at a loss to figure out
how I would continue with this in a P2-only world.  Is there any way to
use P2 in a scenario like this?  For obvious reasons I do not want to
have customer authentication tied to a feature installed in Eclipse to
control policies.  I'd like to keep this completely server-side.  Does
this mean I basically need to stick with a site.xml file?  Does this
mean that I can't pre-generate my metadata, or use a pure P2 solution?

Thanks in advance,
Mark.