Shipping Eclipse each year is a lot of work. The SDK contains code from 3 Top level projects (Eclipse, RT and Tools (Orbit)). There are 4+ Products (Platform, JDT, PDE , Equinox + Releng) and close to 20 Components (SWT, Text, UI, UA, etc…).  Once the SDK is built, the release train starts bolting on other projects (Mylyn, EGit, CDT, Birt, WPT, etc..).  Getting all these bits in the right place at the right time isn’t easy (although Kim and David sure makes it look easy).

While some teams are actively working on their components, other components are very mature and simply need some TLC from time-to-time.  There is certainly a number of things we could do with p2, but for the most part it works very well.  Pascal has been donating much of his personal time to p2 in order to give it the TLC and polish it needs. Pascal is pretty smart and 10 minutes of his time equates to an hour for most people .  However, it’s not fair that he spends all his free time tracking down problems in order for p2 to makes its contribution to the SDK.

I’m happy to say that I’ll be helping Pascal co-lead the p2 project.  There’s a few things I have planned including

1. Fixing a few recent problems on Java 7 Runtimes
2. Improving the performance of the UI
3. Looking at how we can reduce the size of our metadata (content.jar)

I’ll also be presenting some p2 related work at EclipseCon.  If you have questions, I try to hang around IRC and I’m also on twitter (@irbull).

EclipseSource now has a 2 day course that focuses entirely on the p2 API.  Like our other courses, our p2 course reinforces the theoretical concepts with hands-on exercises.  The course covers a wide variety of concepts, including:

1. The Agent
2. The Metadata
3. The Artifacts
4. The Profile
5. The Planner
6. The Engine
7. Building / Publishing p2 repositories
8. Touchpoints
9. Dynamic Provisioning

Throughout the course, the students build a working installer for Eclipse RCP / OSGi applications. The exercises demonstrate proper use of many parts of the p2 API.  In the final section we add dynamic provisioning, enabling the installer to manage and update itself.

The coures is ideal for anybody building a custom provisioning solution, or those looking to extend their knowledge of Eclipse RCP or OSGi.  Please contact us for more information on this course, or any of our other Eclipse based training.

Pascal Rapicault, DJ Houghton and I have been hacking on a new feature for p2. Since p2 has been migrated to Git, we created a new branch and started hacking away. We were not very concerned about each individual commit since this work was mostly experimental. We took some wrong turns, performed a few quick and dirty hacks, and generally left our branch in rough shape. However, during the process we learned a lot and finally got feature working, but we certainly didn’t want to merge this hack into master.

If 15 years of software engineering has taught me anything, it’s that you should not be afraid to hack, learn, throw away and then implement properly. Git makes this so much easier.  Here’s what we did.

To review, clean-up and commit this feature, we started by switching to our new branch and we squashed all the commits into a single commit. We did this because we didn’t care about the individual commits that made up this feature. (Note: Don’t do this on a production (shared) branch since this will re-write your history).

To squash commits, use interactive rebase.

Once we had a single commit that represented the feature, we rebased on top of master and merged the feature to the master branch. Now, we could stop here but this included all the hacks, false starts and ugly code that we don’t want in our final repository. We used a little trick that Chris Aniszczyk mentioned to me.  We reset the git index, but left the files in their updated state (read more about the Git index on Alex Blewitt Git Tip of the Week). This is done using a soft reset.  Make sure you don’t reset your index if you have already pushed your changes to a remote repository.

This essentially returns you to a state where all the files have out-going changes that represent the work we did. Now we could use git diff (or better yet, the s synchronized view in Eclipse) to review the commit, clean up the code, remove the unwanted changes, test our feature and finally, commit the feature properly (using a proper commit comment to indicate exactly what we did).

The Eclipse Packaging Project defines pre-configured Eclipse distributions.  If you are develop in C/C++ there’s a package for that. If you need to create RCP applications there’s a package for that. Using p2 or the Eclipse Market Place you can customize your install until your heart’s content.

However, each time you download a new package, you’re most likely downloading the same 80-90M.  You are downloading SWT, JFace and maybe even the JDT over, and over and over again.  These Eclipse installs begin to clutter your machine and remembering which install contains which plug-in becomes practically impossible.  I currently have 17 different Eclipse installs on my machine:

Over the past few months I’ve been working on a solution to this problem, and now you can provision your own tool chain, the way YOU want it, from the cloud — and share all your plug-ins.  All you need to do is download and install the Yoxos Launcher.  When you start Yoxos, you will be prompted to select a pre-configured EPP Package (or you can also select “advanced mode” and create your own package).   You can even share the configurations between team members to help you get up and running faster.

All the artifacts are hosted on Amazon CloudFront, so the download should be pretty quick (I provisioned an entire ‘Eclipse Classic’ in under 5 minutes).  And all your plug-ins are shared between installs, so if you install a second package, Yoxos only downloads the new stuff it needs.

Using the Yoxos Customizer Perspective, you can add new components and craft your own customized Integrated Development Environment. The Yoxos repository holds almost 2,000 components including everything from Indigo.

Finally, you can set your upgrade strategy. That is, you can tell Yoxos that you want to receive all updates as they happen, or you would rather stick to an exact Eclipse version.

So to recap:

• Almost 2,000 components are available
• All the components have been tested to ensure that all required dependencies are available
• All the artifacts are hosted on the Cloud (AWS CloudFront)
• All your plug-ins are bundle-pooled and shared between installs
• You can configure your upgrade strategy
• The service is free, go ahead and try it.

Tags: indigo

When most people think about Eclipse they think of a kick-ass IDE. While this is true, Eclipse is so much more.  Did you know that Eclipse hosts a top-notch webserver (Jetty), a framework for building Rich Internet Applications (RAP), a Java persistence solution (EclipseLink) and a foundation for building multi-tier enterprise client / server applications (Riena).  In fact, there is an entire top level Eclipse project dedicated to Eclipse RunTime technologies.

The common tread that runs through almost all Eclipse projects is the highly modular component model and the OSGi runtime that enables it.  In addition to the OSGi runtime (Equinox), Eclipse also provides a powerful provisioning platform (p2) optimized for OSGi .  Number 9 on my Top 10 Indigo Feature list is the improvements to p2 and Equinox.

p2 has come a long way since it’s humble beginnings.  While p2 certainly had its share of growing pains, most people don’t realize that the entire Eclipse release process (and release train) would not be possible without p2.  The popular MarketPlace Client would have never functioned with the old Update Manager technology.  p2 has now matured to a stage where it just stays out of your way.

There are a few notable improvements to p2 this year including the ability to save your current Eclipse configuration:

and tag configuration states.  This should make it easier to try out new functionality and return to working state with ease.

Kudos for the import / export work goes out to Meng Xin Zhu.  Dean Roberts gets the shout-out for the tagging feature.  Special thanks goes out to DJ Houghton, Matt Piggott and Pascal Rapicault for improving the stability of the p2 platform and keeping our builds green.

The Equinox project also received some love this year. Tom Watson and John Ross continued to improve the framework and compendium service.  In particular, Equinox was updated to support the OSGi 4.3 specification. This includes a number of enhancements including new framework hooks, weaving hooks and generic capabilities.

On Tuesday, Pascal and I presented “p2, your savior or your achilles heel? Everything an Eclipse team needs to know about p2” where we talked about the 10 most common pitfalls developers face when using p2. More importantly, we talked about how you can avoid them.

For those of you who attended the talk, thank-you.  I hope you learned something.  For those of you who could not attend, I’ve attached the slides here.

Tags: eclipse, equinox, OSGi, p2