[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 12:41:53 -0700
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcnP814vBtNQ7Oz4RyC3N3kaVMlEzAAEa8MwAAPdhFA=
- Thread-topic: [p2-dev] IU Visibility and Server-Side IU Filtering
Sorry to keep answering my own questions, but this is for the benefit of
others searching or reading the list.
It looks like composite repositories will do what I want if I slice my
products up into smaller repositories, and generate the composite .xml
files (which are just pointers to the other folders) on the fly the same
way I was generating my old site.xml.
Out of curiosity, does anyone know if nested, composite repositories are
supported? For example, can I have a composite repository point to a
> -----Original Message-----
> From: p2-dev-bounces@xxxxxxxxxxx
> [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Mark Melvin
> 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:
> 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
> > 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
> > 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