> Sent: May 8, 2009 1:58 PM
> To: P2 developer discussions
> Subject: RE: [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=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
> >
> _______________________________________________
> p2-dev mailing list
>
p2-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/p2-dev
>
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
