Inspired by David Orme’s retrospective on Eclipse — and with the 10th anniversary of Eclipse almost upon us — I though I would share my personal history with the Tool, Platform and Community.

I first used Eclipse in January 2003.  I just finished my Master’s degree at the University of Waterloo and started a PhD at the University of Victoria.  I was at the IBM Toronto lab (I was there as a student full time from Jan 2003 – Aug 2003 before we moved out west).  My Master’s degree was in reverse engineering, C/C++ fact extraction and software architecture abstraction. My PhD took me completely out of my comfort zone as I started running user studies to see how people interacted with complex business process diagrams using WebSphere Studio (an IDE based on Eclipse).  The visualization tools were built with GEF — leading me into my first Eclipse project, the GEF project.

Dr. Storey, and some other researchers at the University of Victoria, were also looking at how Eclipse could be customized for teaching computer science.  This was known as the Gild Project.  I was loosely involved and helped out where I could.

At IBM I had the pleasure of working with Mike Beltzner. He ended up leaving IBM to take a role as the Director of Firefox at Mozilla. With the shuffling at IBM, I ended up working with a new product team, one which consisted of Ed Merks, Marcelo Paternostro, Dave Steinberg, Nick Boldt, and others. Yes, it was the EMF team.

This was before there was a Top level modeling project, before GMF or Xtext.  In fact, I remember some really interesting discussions with Ed about how EMF was going to support these fancy new generics that Java was introducing. I certainly didn’t realize at the time how lucky I was to be working with such a great group of people.  I consider Ed to be my first Eclipse mentor.

Part of our research led us to design a graph based visualization tool built for Eclipse.  I had this idea that we could mimic the simplicity of the SWT/JFace API for visualization widgets.  I met Erich Gamma at OOPSLA 2004 and he encouraged me to explore this.  My supervisor (the awesome Dr. Storey) managed to secure some funding and we hired some help and got to work.  This work eventually became Zest, and I first spoke about it at EclipseCon 2005 (my first EclipseCon).  At EclipseCon 2005, I met Mik Kersten, and he was interested in visualizing task contexts in Mylyn (Mylar at the time). We decided to make Zest an OpenSource project as part of Mylyn (Mylar).  I consider Mik to be my second Eclipse mentor. Eventually it became obvious that Zest was more general than a context visualization tool, and Zest was moved to the Graphical Editor Framework.

In 2006, a group of us from UVic got together to hack out a new Plug-in. We called the event “Raise a Plug-in”, and the result was “TagSEA: a tool for tagging and navigating source code“. In 2007, I attended EclipseCon again to talk about Zest (and TagSEA), and it was here that Chris Aniszczyk and Wassim Melhem convinced me to do a Summer of Code project building a PDE/Visualization tool using Zest.  I consider Chris and Wassim to be me third and forth Eclipse mentors.

By 2008, my PhD was finishing up and I was looking for work. When asked what do you want to do when you grow up? My answer was simple… I want to work on Eclipse.  So when Jeff McAffer contacted me about joining him at Code 9, I jumped at the opportunity. Jeff immediately put me to work on p2 where I had the great pleasure of working closely with Pascal Rapicault and the other talented committers on the p2 team. I consider Jeff and Pascal my fifth and sixth Eclipse mentors.

Since 2008, a few things have changed at Code 9.  For one, it’s now called EclipseSource. I still work on p2, but I also spend time leading our Yoxos product development. With over 300,000 Eclipse plug-ins in our archive, I get to see a different side of the ecosystem.  I also spend time thinking about Eclipse / OpenSource business models and work closely with my 7th Eclipse mentor, Jochen Krause.

I literally sit in my basement and hack Eclipse — a pretty awesome job.  I occasionally give lectures about software engineering and other computer science topics. When asked: why do you like working on Eclipse the answer is simple: The people. Where else could I work with Ed, Mik, Chris, Wassim, Jeff, Pascal and Jochen?  All companies have smart people, the Eclipse community has the smart people from all these companies.

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).

With summer behind us and autumn almost here (in the northern hemisphere), you can feel the change in the air.

The Eclipse and Equinox teams have made Juno Milestone 2 available, however, these milestones are no longer based on the Eclipse 3.x stream. Starting with this milestone, we will be encouraging users to actively test the 4.2 stream. The Eclipse Juno release (coming June 2012) will be based on the 4.x stream.

There are a few goodies in this release including Quick-Fixes for loop refactoring:

An enhanced Ant editor:

And some fancy new transitions:

Checkout the entire New and Noteworthy. Or better yet, download the milestone and take it for a spin.

Tags: juno

Eclipse is turning 10 this fall! My first experience with Eclipse came 8 1/2 years ago when I started building visualization tools on top of GEF. I was an IBM CAS Student while doing my PhD at the University of Victoria. Over the years I’ve attended several demo camps, presented Eclipse content at the local Java User Group, delivered presentations and tutorials at numerous EclipseCons and even attended the occasional Eclipse stammtisch. However, I’ve never attended an Eclipse conference in Europe .

I’m hoping to change that this year so that I can join in the Eclipse 10th anniversary celebrations.  I’ve submitted 3 talks to the conference:

• p2, your savior or your achilles heel? Everything an Eclipse team needs to know about p2: This is re-hash of the talk Pascal and I gave an EclipseCon 2011 (the one in North America). We highlight 10 things that all Eclipse developers need to know about p2, or at least the types of things that will make your life a lot easier.
• It’s Raining Bytes: Scaling p2 Using the Cloud: In this talk I will discuss how we use p2 to build something as complex as the Yoxos distribution. Yoxos contains over 30,000 artifacts, split across dozens of self contained slices and all delivered using the Amazon Cloud services.   Each one of these components has been validated to ensure that it installs and that all dependencies are available. This talk is intended for those looking for practical advice on how to scale p2 (the eclipse provisioning platform).
• Moving from CVS to Git, 10 things I’ve learned: This talk was inspired by a blog post a wrote a while ago, when I was first learning Git. I often find that once someone starts using Git heavily, they forget about the growing pains they went through.  With these pains still fresh in my mind, I hope to use this opportunity to present 10 things I learned along the way.  This talk is geared towards those just starting off with Git.

I hope to see you in Germany this fall.

Lately I’ve been adding Git support to the Yoxos Workspace Provisioning. This should be done in time for Eclipse Indigo SR1 and this will mean you can easily share your Git configurations in your Yoxos profiles.

I wanted to make it easy to share your existing repository settings, but unlike CVS or SVN, sharing your Git repository makes very little sense.  Likely you want to point someone to a remote (say one you have shared on GitHub). This means I needed to read the repository settings, find all the remote repositories and order them (such that the one called ‘origin’ is on top).

This turns out to be very easy with the JGit API.  JGit reads the configuration information and stores it in a properties style object where the values are keyed based on their subsection and name. You can get a list of all the remotes by asking for the remote subsection. From here, you can get each remote URL by asking for the URL to a particular remoteName in the remote subsection.

The following code prints out each remote and its URL.

package com.ianbull;

import java.io.File;
import java.io.IOException;
import java.util.Set;

import org.eclipse.jgit.lib.Config;
import org.eclipse.jgit.lib.Repository;
import org.eclipse.jgit.lib.RepositoryBuilder;

public class RemoteReader {

  public static void main(String[] args) throws IOException {
    Repository repository = new RepositoryBuilder().findGitDir(new File("/home/irbull/git/p2")).build();
    Config storedConfig = repository.getConfig();
    Set<String> remotes = storedConfig.getSubsections("remote");

    for (String remoteName : remotes) {
      String url = storedConfig.getString("remote", remoteName, "url");
      System.out.println(remoteName + " " + url);
    }
  }
}

While I’ve been enjoying some time-off in Northern Ontario, many Eclipse committers have been keeping busy.

I hope everyone managed to get their hands on the Eclipse Indigo Release, although the Eclipse team is already hard at work preparing for next summer.  The next release — Eclipse Juno — will ship in late June 2012 but the first milestone is already available.  This milestone includes Java 7 support.  Also, many of the components are now being hosted via Git repositories.  As you can imagine, moving 10 years worth of code from CVS to Git is no easy task.

The complete New and Noteworthy is available:
http://download.eclipse.org/eclipse/downloads/drops/S-3.8M1-201108031800/eclipse-news-M1.html

And you can download the Milestone:
http://download.eclipse.org/eclipse/downloads/drops/S-3.8M1-201108031800/index.php

Enjoy!

A number of people in the Eclipse community have been trying out Google+ and some good Eclipse related discussions are starting to happen there. Since many of us have multiple Google accounts (maybe your company uses google apps, or you have your own google apps for a custom domain), switching between accounts starts to become a real problem.

Of course, you could run multiple browsers (say Firefox for personal mail and Chrome for corporate mail), but this is not an ideal solution.  Last week while struggling with this problem I found this little helpful hint.

Now you can navigate to your Google accounts page and enable multiple sign-in.

This is obviously not Eclipse related, but I hope this helps a few people.

It’s interesting to see how Eclipse projects change over time.  As projects ramp up, hit heavy development and finally start to mature, the flurry of activity changes.  Git makes it very easy to pull out this information. I wrote a small script that shows the number of commits per person, per year (and the total number of commits for that year).  I defined a year to basically be an Eclipse release (July 1 – June 30).

While you shouldn’t read much into any one year (or one person) — and you certainly can’t compare projects with this data — the trends are where the interesting information lies.

Feel free to try it out yourself. Simply put the script in the root of a git repository.  The script goes back as far as Eclipse 3.1 (feel free to add more years).

https://github.com/irbull/gitscripts/blob/master/yearly_stats

Note: This is nothing new. You could also use Dash or look at http://www.ohloh.net/.  These scripts just use git log.

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