Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cross-project-issues-dev] p2 update

Speaking from BEA's perspective, which I expect echoes David's quite closely in this regard:  what will ultimately be important for our enterprise customers is a story that (a) allows for controlled patching and upgrading, that is, the ability for IT or a tech supporter to easily determine the state of an install and apply or remove patches and upgrades; and that (b) allows IT departments to "lock down" installs such that the end user of Eclipse cannot upgrade or apply patches except when, if, and where the IT department wants.  (Part "b" does not reflect my own feelings, but I have encountered that requirement many times from customers.)
Meanwhile, individual devs, like most of us on this list, probably will be happiest with a story that lets us do whatever the heck we want with as little change as possible required until we get a free moment.
So, hurrah for S/P/J's efforts, they're appreciated!  And yes, it'll be good if this can be made optional.
I do worry about how we'll educate users around the inevitable confusion of "what's the difference between the two locations".  There will be a lot of outdated misinformation floating around.

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Thursday, March 27, 2008 5:08 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] p2 update

Yes, we are familiar with this directive in the platform as well. I have an old workspace on my machine created by a preview beta of Eclipse of June 2000. I just tested and confirmed that this still loads with today's 3.4 M6 candidate.  We didn't just decide to intentionally break this and then change our minds. We really believed we couldn't support this same functionality while also supporting the core new functionality of p2 that people have been asking for (bundle pooling, phased installs, multi-user installs, etc). We were wrong. After a long night Pascal found a way to make this work, and Simon, Pascal and Jeff implemented this the next day. I suspect it will end up remaining this way by default as long as there are users who care about it (i.e., forever). We will likely make this optional so that users who don't want to pay the associated startup cost, or products that don't want their users messing with this directory, can disable this functionality. But, the default out of the box experience for Eclipse 3.4 will be to support it.


Back to the top