[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] IU Visibility and Server-Side IU Filtering

Not to make you answer your own question again ;), but if you find out about nested composite repos I would love to know the answer. I would assume yes, but I don't know if that has been tested.

cheers,
ian

On Fri, May 8, 2009 at 12:41 PM, Mark Melvin <Mark.Melvin@xxxxxxxxxx> wrote:
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
composite repository?

Mark.


> -----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:
>
> 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



--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource