[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] RE: Anybody using p2?
|
Title: Anybody using p2?
I do know Red Hat was
contributing to p2 to support shared installs in this manner. And Profiles
make extension locations unnecessary since they pick can pick and choose what
bundles to use for a given install. I don't know the details and I
agree that p2 is missing a lot of documentation on how to do these things. But
being in the bowels of p2 as I have, I can see how it is possible to solve
your problem.
Ace :). In the long term I can
definitely see the benefits of a modern update manager; perhaps documentation is
the missing key. I just wish I had the p2 features with the
ease and flexibility of old UM.
With this particular use case,
profiles don't seem like quite the right match. To me that
sounds too high level -- the documentation suggests profile's
are a course product level decision rather than a user feature
level decision. I want to be able to say to a user hey, here's how you
run a basic Eclipse platform: it has CDT, Java & CVS.
If
you find you're working on a project with clearcase, or need to dip into python,
or whatever, just add an extension location like so. With p2 it's all or
nothing -- or do you end up with a combinartorial explosion in profild
ids?
James
Doug.
Hi Warren,
This is just a general question for
people building IDE's based on Eclipse 3.4 and CDT 5.x. I'm
wondering how many people are using p2 and how many are sticking with the
old updater. We've run into a lot of issues p2-izing our products
and are considering sticking with the old updater for now, possibly moving
to p2 when Eclipse 3.5 comes out.
I'm in a similar situation. Our Eclipse
install is used exclusively by users internally -- and for that I maintain a
slightly modified shared install. For this use case p2 has no
equivalent behaviour to the old update manager's shared
install platform and centralized extension locations (as far
as I've discovered). When "adding an extension location" p2
copies the plugins and features from the read only share directory to
the user's local configuration. We can't afford to do this due to disk
space constrains.
For managing multiple versions centrally p2's idea
of bundle of features doesn't apply. In this scenario how does one
version Eclipse orthogonally to pydev, clearcase, epic, etc.
etc.? I can't mess around with an installed
version once it's made because users are using it. In
the old world adding a new version of an external tool wa sas simple as
creating a directory, touch'ing .eclipseextension, and go! Needless to
say I filed a bug about shared install being left out (and other more
minor things along the way): https://bugs.eclipse.org/bugs/show_bug.cgi?id=241730
However it looks like the world of everyone with
there own 300Mb platform has eclipsed (haha)
the shared install centrally managed world that unix guys are used
to...
In brief, our release has been
de-p2ised.
Cheers,
James
PS I'd be very interested in hearing
from anyone who's using a p2 Eclipse in the old shared install way and
how they do it!
Thanks,
Warren