No not that p2 – P2 the movie. Given the discussion about our p2, I just couldn’t resist. 🙂
I know the p2 team is working extremely hard to make p2 a killer feature. Making any change as significant as p2 will always strike fear in people, including me. However, one thing I am finding is that some people don’t appreciate what p2 buys them. Therefore, with some input from Pascal, Jeff and others, I bring you the top 10 reasons p2 is going to rock.
- Automatic retry of download across all available sources
- Transparently picks the best mirror
- Bundle pooling allows sharing of plug-ins across multiple eclipse instances
- Ability to manage the complete installation (exe, ini, etc)
- Ability to manage and update an Eclipse instance without running it
- Makes is easy to create headless and custom update user interfaces
- Validates plug-in inter-dependencies so you only install plugins that work together; if you can install it runs.
- Multi-threaded download making downloads faster
- Only installs plugins that you need, so it reduces the number of plugins installed
- Create uber-update sites that know how to get plug-ins from multiple sources
- P2 means you never have to install Eclipse again, you just need to update.
Feel free to add to this list.
btw, I don’t mean to discount the concerns that have been raised. It is important that the community have these discussions and I hope they continue. Changes is always hard, especially understanding the impact it will have on everyone.
btw, thanks to mcq for the tip on the p2 movie.
14 thoughts on “P2 – A new level of terror”
The complete install is the big thing with the C/C++ IDE community. We all deal with compilers, debuggers, libraries, header files. The ability to use the same install technology to install that as well as getting all the other benefits you mention has a lot of vendors very interested in the work I’m doing to make that happen with my products.
Somehow the corporate Eclipse installation concerns have been lost in that list of yours.
From my point of view P2 adds nothing new, and just changes things around for the sake of changing things around.
1) In a corporate environment that is ripe with IP concerns and locked down internet access, this feature is useless.
2) Same as #1
3) This is possible in all pre-P2 Eclipse installations too, and can be remotely administrated as well.
4) Same response as #3
5) Been there, done that, in pre-P2 Eclipse installations as well. still no net gain for P2.
6) Did you know that pre-P2 Eclipse installations can do this too?
7) Something that the current pre-P2 Eclipse installation can do too, just have to be smart about your update site choices. (Which is really easy to do when you have to have full control in a corporate environment.) After all that information is already present in the site.xml, and feature.xmls.
8) Same as #1
9) Score 1 for P2 / 8 for Pre-P2 (so far)
10) Same as #1 (not controlled enough)
11) Well, only true after the first install. But again, this isn’t a problem in a Corporate Environment. But ultimately, reason #1 rears its ugly head again. IP concerns mixed with auto update results in fear in many corporations.
So, end result of the Is going to “Rock list” is …
5 features that have no value in the corporate life.
5 features that can and are being done already in pre-P2 Eclipse Installations.
1 feature that is possibly useful.
Things that are missing from the P2 discussion.
Using the central bundle concept, is it possible to test a new version of a plugin, and based on results, either disable that version, or go back to a previous version?
What about a corporate plugin repository with the ability to flag / mark certain plugin ids as DISALLOWED or DONOTUSE or BUGGY?
What about the ability to flag certain plugin dependency paths as problematic?
Those kind of features would make us corporate eclipse installation types sit up and take notice.
Also, I maintain 4 different eclipse installations, Standard, JEE, PDE, and C. I intentionally keep them separate due to resource and plugin development / testing reasons. I can even reset each installation to ‘baseline’ in about 5 minutes. Can P2 function / help in this scenario?
> 10. Create uber-update sites that know how to get plug-ins from multiple sources
HOW? Is there documentation for this?
> 11. P2 means you never have to install Eclipse again, you just need to update.
I’ve tried this numerous times since M6 (Help > Software Updates… > Installed Software > Eclipse SDK > Check for updates…) and Eclipse never finds an update for the Eclipse SDK feature.
Great list. However, concerning point 2), it doesn’t seem to work all that well in practice. Just yesterday, i selected something to install from the Ganymede URL and p2 started download from a nervewreckingly slow mirror in Thailand or so while i have various up-to-date mirrors with blazing speed in Germany. I really be would interested how this feature works technically.
We went to Thailand because we had a silly bug in a compare method which was making the slowest mirror the one of choice :-). This got promptly addressed in RC2.
In response to Joachim
Re. 1/2 (Mirroring and picking). This is indeed paramount for large companies where multiple mirrors can be available. For example in IBM we have 4 north american internal mirrors of eclipse downloads to off-load the foundation. Also picking content become a non-issue when your content is signed and Md5’ed. In addition to that p2 offers in its core the ability to control the set of repository consulted for each operation.
Re. 3 (Bundle pooling) This was not possible. You had an erzatz of bundle pool through extension locations. However that meant that you had to keep track of the extension locations and their dependencies and knew what was made available to every configuration. The bundle pooling we are talking about allows to put in one folder the plug-ins of all your eclipse based applications. For example my Sametimes plug-in are located in the same folder than all the plug-ins of all my IDEs. Extension locations had a lot of drawbacks that I will talk about at another time.
Re. 4 (manage complete install) If you are talking about install handlers. sure everything was possible there. You could turn Eclipse into a car. However there was nothing out of the box. Here we have API to do this. This is different.
Re. 5 (ability to update eclipse without running) Please give me the steps!!! This is a lie, the PDE team and others have been struggling with this and unless you rolled out your own solution that was not possible. If you are referring to the usage of links folder and such… sure, whatever. But here we are talking of the ability to create a complete installation from a metadata description which will result in a completely configured system (including ini files without downloading them but by reasoning about them).
Re. 6 (create headless and custom update) I agree. But the level of modularity provided out of the box for someone willing to build his own system is just magnitude more.
Re. 7 (um managed dependencies) This is pure lie. I encourage you to look at the code. Update manager was forcing you to duplicate the infomration of your feature in your plug-ins and was not handling import/export package dependencies. Here the information expressed in manifest.mf is used and an optimal solution is found. In its core p2 can do plug-ins level provisioning.
Re 11. this again the comment of someone who has simply looked at the UI side of things. p2 decouples what you have installed from who is the provider and where it has been installed which was not possible before since features always had a pointer back home. With p2 you can install the SDK on your users machine and only make available in their install the sanctioned repository of your company, thus controlling everything they see and get. You can also disable the UI to prevent them to get only what you want, and also the ability to discover plug-ins laid down on the file system.
>5 features that have no value in the corporate life.
The suit does not make the man. Again here I think you have limited your judgement on the list without taking time to try it or understand p2. In corporate environments, p2 is right on (would IBM pay me for this otherwise) as it provides fundamental building blocks and control points necessary. Of course it does not provide everything you may have dreamt of but you have to keep in mind that the scope of p2 has been purposely crafted to not overlap with the eclipse project Maynstall (and now its commercial version Pulse (based on p2 btw)).
>Using the central bundle concept, is it possible to test a new version of a plugin, and based on results, either disable that version, or go back to a previous version?
The bundle pool is not an extension location. Therefore you don’t get things for free. You only get what you said.
> What about a corporate plugin repository with the ability to flag / mark certain plugin ids as DISALLOWED or DONOTUSE or BUGGY?
p2 allows the installable bits (IUs) to be categorized and annotated. So you can do that if you want. However I think that concepts such as DISALLOWED/DONOTUSE are probably context dependent and that starts to be on the realm of Maynstall.
> What about the ability to flag certain plugin dependency paths as problematic?
If the dependencies are problematic p2 will tell you at install time.
>Those kind of features would make us corporate eclipse installation types sit up and take notice.
This is out of scope for p2. p2 scope has been defined to provide enabling pieces at the core of eclipse and let the enterprise / control side to Maynstall.
>Can P2 function / help in this scenario?
Like for RPM or other management system, if you don’t specify a repository, if the repo is empty or bogus, this is not management system fault but the maintainer of the repo.
Anyone care to explain what this all means? It looks like another case of technical mavens talking to themselves.
A few simple use case scenarios to show what those of us who never used the features that p2 is trying to replace would be nice.
1. Automatic retry of download OF WHAT? across all available sources
2. Transparently picks the best mirror FOR WHAT?
3. Bundle pooling allows sharing of plug-ins across multiple eclipse instances
AND WHY WOULD YOU WANT TO DO THAT?
4. Ability to manage the complete installation (exe, ini, etc)
AS OPPOSED TO WHAT?
5. Ability to manage and update an Eclipse instance without running it
WHY IS THIS OF USE?
6. Makes is easy to create headless and custom update user interfaces
EH? WHAT IS A HEADLESS USER INTERFACE? GOOD TO KNOW THAT ITS EASIER WITH P2, THOUGH.
7. Validates plug-in inter-dependencies so you only install plugins that work together; if you can install it runs.
THAT SOUNDS GOOD.
8. Multi-threaded download making downloads faster
NOW HERE”S ONE EVEN I CAN UNDERSTAND!
9. Only installs plugins that you need, so it reduces the number of plugins installed
GREAT. SOUNDS GOOD.
10. Create uber-update sites that know how to get plug-ins from multiple sources
WHAT? HOW ABOUT AN EXAMPLE TO HELP PEOPLE LIKE ME UNDERSTAND WHERE AND WHEN I WOULD NEED THIS?
11. P2 means you never have to install Eclipse again, you just need to update.
HMM! UPDATE WHAT?
THANKS FOR ALL OF THE WORK, BUT PLEASE REALIZE THAT FOR PEOPLE TO ADOPT ANY KIND OF TECHNOLOGY THEY NEED TO KNOW WHAT USE IT IS, AND THAT MEANS THAT THOSE WHO KNOW NEED TO TAKE A BIT OF TIME TO EXPLAIN AND NOT ASSUME THAT EVERYONE ALREADY GETS IT.
I’m also seeking documentation/example of how to create an uper-update site. I’ve found nothing on the P2 wiki.
Hey, i’m seeking such an example, too. Does anyone know one?
All sounds good…but it is difficult to get p2 working. No simple way of doing it…no proper documents available. whatever documents are available they has lot of command which are difficult to follow. And somehow if you manage to run them, then one will wonder what to do next with that….i will wait until p2 become more refined and sophisticated.
> …know the p2 team is working extremely hard
> to make p2 a killer feature…
I must be drinking the wrong kool-aid because I’ve found that the p2 feature is a product killer. I have wasted alot of time and effort to build a product release that does not update due to bugs, missing documentation, and misleading examples.
I would recommend that you stay away from p2 until at least Eclipse 3.6 or later. If you want to try it, treat it as alpha release code.
It has been an extremely frustrating experience. The worst I have had with an Eclipse tool.
We have been using P2 internally now for the past 6 months on Eclipse 3.7 and have had great success with it. We’ve had to tweak a few things here and there, but overall the feature is great. We are using the JNLP to launch the install, automatically adding optional update sites, etc.
Comments are closed.