> 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@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/p2-dev