As we hinted at EclipseCon last week, my team has been evaluating p2 as the framework for our new installer technology. We're essentially coming from an InstallShield world where we have these big monolithic setup.exe type things and we are looking to make our installs more flexible and open the door to electronic distribution. It's an exciting vision and we're pumped to be working to make it happen.
I've talked to the p2 team off an on over the last while trying to get a sense of what they were doing. But it really took Pascal's p2 long talk for it to really hit me. p2 is the new Update Manager (duh, that's what they've been saying all along). But as I look under the hood, it's an Update Manager on steroids (good thing there's no drug testing of software). And it's really got us excited.
The beauty of it is the extensibility. The underlying concepts are sound and based on some pretty standard notions albeit with weird names. InstallableUnits and Artifacts, what's the difference? Once you get past that you're fine. But the fact that you can override how things are installed with Touchpoints, and the fact that you can override how the Repositories are stored opens the door to some really exciting opportunities.
Aside from my internal work, I am looking to make a p2 based installer for Wascana. Yes, it can be used to install the Eclipse bits for the Platform, CDT and other plug-ins I need. But it should also be possible to use it to install the toolchain and libraries as well. What also struck me is that I should also be able to install the bits directly from their own download sites. This will allow me to quickly make available new releases of the components. The flexibility will still allow me to create off-line installs as well.
Another thing that popped into my head was whether p2 could be adapted to install Linux packages. Every distribution pretty much has it's own package manager. It would be very interesting if we could get p2 to install RPMs for example allowing us to use the same UI to set up Eclipse as well as packages, or even allow us to set up dependencies between them. Then we could create a Linux toolchain integration plug-in that depends on the compilers and have the p2 installer install the whole thing.
So as you can see I have big dreams for p2, probably more than the p2 team can handle at the moment. But it's an area that I really want to get involved in and contribute. And we'll see where we end up.
I've been asked more than once about integrating the update manager with the distribution update manager. While I personally think having multiple UIs to do the same thing is silly, p2 does open that door.
ReplyDeleteHello Doug, p2 sounds promising as installation system. I think that if p2 were integrated with rpm's and deb's packages in linux boxes will be great for Wascana-like distributions, that integrate Eclipse+plugins+toolchains.
ReplyDeleteI'm a assistant professor of a spanish university. With my team I have made an Eclipse distribution, EclipseGavab (http://www.gavab.es/eclipse), for teaching. It contains all bits for C/C++, Ruby, Pascal, Java and Ruby and the C/C++ bits are Wascana based. Because is targeret to students, we needed a easy-to-install app, with all included and of course, we liked to support linux and windows (and in the future Mac).
It would be very interesting if we could make an installer that works in all platforms, that downloads neccesary bits from Internet and that integrates well with package-managers of each platfrom. Of course this requires a lot of work by the p2 team.
In the while, I'm waiting to June to touch Wascana with CDT 5.0.
I will be looking into creating an installer for Padclipse ( http://padclipse.sf.net ) around the time of Eclipse 3.4 release. So far I was considering NSIS, but the p2 installer seems like a viable choice as well. I wonder if it can do OS specific stuff, such as add registry entries on Windows?
ReplyDeleteThe issue I'm still grappling with is that, as Pascal said in his talk, unzip is not install. Yet we still have to unzip an Eclipse based installer to start it up. We need to find some way to create an executable that contains and launches p2. My current thinking is to use NSIS to make an installer installer that installs and launches p2 in a user specified directory. We'll need a similar story for the other platforms.
ReplyDeleteDoug, thx for the nice words, I'm looking forward working with you.
ReplyDeleteVillane, currently p2 offers little OS integration (registry keys and the like) mostly because we don't have much time writing the native code. Once it is available, integrating it in p2 is really trivial.
Dough,
ReplyDeleteP2 doesn't update the plug-in jar between uninstall and re-install. Only solution is to write some code that removes all files from eclipse installation that pertain to plug-in. So does p2 provide any api to plug-in developer which can be used to write a custom un-installer in which all references to the plug-in can be removed? Here is the link to a related thread in the newsgroup : http://tinyurl.com/prkobj
Thanks.
Hi Doug,
ReplyDeleteI know this is an old thread, but I wonder if you have looked at the new P2 and its JNLP installer? This allows you to launch the install via HTTP (or a file share or whatever).