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

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

OK, well after reading through a whole pile of bug reports on the issue
of categories and IU visibility (in particular
https://bugs.eclipse.org/bugs/show_bug.cgi?id=227675 and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=262009), it seems the bit
about letting site authors specify what they wanted to be visible or not
was lost in the noise when these things were resolved.  However, I
recalled a trick I saw in the p2.inf file for the RCP configuration
feature that didn't work pre-M7 but supposedly worked now - setting the
group property of the IU to 'false'.

As it turns out, if I stick the following in my p2.inf file:

properties.1.name=org.eclipse.equinox.p2.type.group
properties.1.value=false

And build with a post-M7 build, my IU is marked with
org.eclipse.equinox.p2.type.group=false, and if it is not listed in any
categories it doesn't show up in the flat listing of all features on a
P2 repository.  I've been getting steadily better at magic over the past
two weeks.  I should have been a wizard.

So, assuming this feature is intentional and doesn't go away anytime
soon - that just leaves the dynamic repo contents issue based on HTTP
authentication outlined in my original email.  Is this possible with P2?
Could I build up a dyanmic pointer file that pointed to other repos
perhaps?  I'm not sure how composite repositories work yet - that's
still on my list of stuff to figure out...

Mark.

> -----Original Message-----
> From: p2-dev-bounces@xxxxxxxxxxx 
> [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Mark Melvin
> Sent: May 8, 2009 11:41 AM
> To: p2-dev@xxxxxxxxxxx
> Subject: [p2-dev] IU Visibility and Server-Side IU Filtering
> 
> 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-rep
> ository/)
> 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_RC
> P_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.
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev
>