[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [p2-dev] IU Visibility and Server-Side IU Filtering
- From: "Mark Melvin" <Mark.Melvin@xxxxxxxxxx>
- Date: Fri, 8 May 2009 10:57:43 -0700
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcnP814vBtNQ7Oz4RyC3N3kaVMlEzAAEa8Mw
- Thread-topic: [p2-dev] IU Visibility and Server-Side IU Filtering
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=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:
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...
> -----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
> 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:
> 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,
> p2-dev mailing list