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

This Effective Mockito Post will be IDE specific again but related to the last post on Mockito’s spies. If you’ve read Part 3 you should now be familiar how to use them to “pseudo mock” statics. When writing code it often comes to a point where we want to debug using single step debugging. When using Mockito and especially when spies come into the game there is still something pretty annoying.

That is, when we want to debug our Object-Under-Test’s real method and the object is a spy. When we try to step into the object’s method we always land in internal Mockito code. After a little reading we can drill deeper but the next landing place is in java.lang.reflect code and so on. To be honest, this is really not the nicest way to debug code. What I want is that regardless of whether I use spies or not, when I step into an object’s method I land directly in this method. In the past my workaround was to set a breakpoint in the test at the method call and in the method itself. This enabled me to stop at the first point and resume the execution until it stops the second time in the method. But there is a much more elegant way. Let’s see how we can do this.

First of all, let’s take a look at an example. The code below shows a simple test from the last Effective Mockito post. The test uses a spy to “pseudo mock” a static method. We set a breakpoint in the line of the isPropertySet call and debug this method. Sadly when doing this we run into the effect described above.

@RunWith( MockitoJUnitRunner.class )
public class MyObjectText {
 
  @Spy
  private MyObject objectUnderTest;
 
  @Test
  public void testIsPropertySet() {
    doReturn( "some runtime property" ).when( objectUnderTest ).getProperty();
 
    boolean isPropertySet = objectUnderTest.isPropertySet();
 
    assertFalse( isPropertySet );
  }
 
}

When using Eclipse there is a very simple way to avoid this called “Step Filtering”. We can add packages or classes to this Filterlist using the preferences. When filters are activated the classes will automatically be skipped during debugging. By setting a filter like the one in the screenshot below we can simply step over the Mockito and reflection code.

If you are not using Eclipse there is probably a similar way to achieve this with your IDE. It would be cool if you would share this tip with us in a comment. Meantime, I hope that Step Filtering is as helpful to you as it is for me.  Finally, I want to thank Fluffi and Frank for getting me to dive into this.

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

Tags: debugging, eclipse, Mocking, Mockito, test driven, testing, tips

Munich Democamps have always been fun! Need proof? See here!

We are looking forward to celebrating Eclipse’s 10th birthday at the Democamp in Munich on November 15th. This time the Democamp will be located at the EclipseSource office (Agnes-Pockels-Bogen 1). The seats are limited to 100 so if you plan to attend, please register soon. If you want to present, please send me a description of the demo (jhelming@eclipsesource.com). Depending on the number of submissions, we might have to adapt the slots a bit. Please also register as a presenter.

In addition, I am happy to announce that we will have a keynote at the Democamp. To make it a little more exciting, I will not post the name yet. Instead, there will be a small challenge. This is how it works: I will answer one Yes/No question per day. You can follow this with the twitter tag #demoriddle. You can suggest new questions via twitter and I will pick and answer one every day. The first person with the right answer will get a Bavarian present at the Democamp. (Please do not participate if you happen to know already who it will be.) Each person is allowed only one guess, so take your time and choose wisely.

In Munich, we are currently looking forward to two events: The last week-end at the Oktober Fest and even more important the Eclipse Stammtisch on upcoming Tuesday 6pm. We have already over 20 registrations including the legendary Mr. Eclipse Foundation Europe, Ralph Müller.
Furthermore, we will have interesting demonstrations. Arno will present the Loggifier, a tool that inserts code into Java class files for logging, and the CVSTools. Maximilian and Edgar will present new features of the EMFStore including GIT Integration. Ekke will demonstrate the development of LocationBased Services with the BlackBerry Eclipse PlugIn. And finally I will try to get the KINECT running at Sappralot
However, if you are not in the mood to look at any demonstrations, just drop by for a chat and a drink.
If you have not registered for the Stammtisch yet, please do so: http://eclipsestammtisch.eventbrite.com/
I will update our reservation on Friday.
Looking forward to meet you there!

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

Last week I talked to a fellow developer, Frank Appel, about Mockito. We’ve been using this mocking library for over a year. We both agreed that of all the innovations we’ve tried in the last year or so, Mockito has boosted our coding productivity the most. With this blog series we want to share our experiences with Mockito. You see that I used the word “effective” in the title, and, in this context I want to define “effective” as arriving at clean test and production code as fast as possible.

To understand these posts you need to have a basic understanding of what mocking is. I recommend reading Martin Fowlers article,”Mocks aren’t Stubs“. You’ll also need some practice with Mockito. But, since you found this blog, you probably searched for the term Mockito , so this should be a given. Anyway, there is a third thing, that only affects this first post. You need to use Eclipse as your IDE. This post shows you how to setup Mockito in your IDE for the daily work. If you are using another IDE and you know how to achieve what I have described here, please share your tips in a comment. The follow up posts will not require Eclipse because they will be more Mockito specific. Enough prerequisites, let’s start with with the first thing that will boost your Mockito experience.

I always write tests first. My goal is to come up with a first test method really quickly to be able to create all the classes that I need by resolving the compiler errors using Eclipse’s quick fix functionality (CTRL/CMD+1 is your friend). What would be ideal, is to create a test class and just write the test without importing all the other stuff.  The Mockito and Junit stuff should automatically appear in my content assist. When using Mockito, I want to create a test method, write “mo”, open the content assist and it should show me all the “mock” methods.

I’ll give you an example to make this clearer and to show how to achieve this. If I write a test method and open the content assist (which I use all the time), the standard selection options are very basic.

As you can see there are no “mock” methods but at least the Mockito classes. The reason is that the content assist only shows methods that are imported in the current class. So, by static importing Mockito this can be fixed.

But this is not what I want. This assumes that I have to import all Mockito stuff manually, or that I need to write “Mockito” and organize my imports automatically. I really want to be able to just write “mo” and get a pre-filled content assist. Luckily there is an option that lets us achieve this. In Eclpse it’s called “content assist favorites”. It can be configured within your preferences. Let’s take a look at our favorites.

As you can see, I added Mockito.*, Matchers.* and Assert.* to my favorites. This enables my content assist to show the available methods and import them when I’m using one. You may think, “hey, this will fill my content assist with unnecessary stuff when I’m writing production code.” But this is not the case. These imports are only available when Mockito and JUnit is on your build class path. So, by separating test and production code you only have these imports available in your test projects. Let’s take a look at the result.

As you can see I haven’t imported any Mockito stuff yet but I can select all the mock methods from my content assist. This enables me to write tests really quickly because I don’t have to think about setting up a test, I can just write it.

This is just a simple trick to come up to speed as quickly as possible when writing tests using Mockito. In the next posts I will focus more on the Mockito specifics. I hope you liked it and will stay tuned

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

Tags: Java, Mocking, Mockito, Open Source, TDD, tips

At September 7th I attended the Eclipse Testing Day 2011.

In the morning we heard several talks about various testing strategies in different commercial products. Alexander Klein from BeOne held an inspiring talk about testing the users experience for a product. Among other ideas he recommended to watch users while they are confronted with the product to get ideas for the next iteration.

In the afternoon things became more hands-on. Michaela Greiler presented her Eclipse Plug-in Test Suite. This is a test runner that allows static and dynamic analysis to report on executed extension points and OSGi services. By itself it is merely interesting, but imho not interesting enough to be a standalone project. I think this technology should go as additional metrics in something like EclEmma. Maybe JaCoCo will provide a home? Hear me, Marc?

Jubula was a major point of talk. Felix Ziesel from BREDEX showed how he uses the Eclipse for Testers download to define an automated smoke test suite to test the completeness of the Eclipse for RCP and RAP developers. I hope he will repeat this talk at an EclipseCon where other packagers are present. This just looked as it ought to be, but obviously it wasn’t feasible before Jubula.

The last talk was mine. I presented an example of a full-featured PDE build from a git repository with test automation. Even though it was the last one of a full day of talks the discussion afterwards was interesting and showed I had hit a sore spot in many projects.

At the side where a few booths from various companies. I was excited to see Xored advertising Q7 there. This is a UI testing tool that only supports Eclipse. Because of this exclusiveness the scripting language gets right to the point. Capture and Replay functionality is also available. Why was I excited about that? – Coming as complete outsiders, they did a talk at last years Eclipse Testing Day about this side product they developed to make testing their application easier. It was extremely well perceived and for a while they where the focus of attention with this thing that’s now Q7. I’d really like to see them more involved with the Eclipse community. Specifically I think their tool might be in a good position to allow UI testing for a RAP workbench.

As a conclusion I have mixed feelings about the Eclipse Testing Day. It shows that things are moving and keeps a handful of people talking. I think it could be a real benefit for the community, if it would show up. But while last year all talks where held in english, now only 3 out of 10 did so, making the Testing Day too much of a german and too less an international event. Many key players where missing. Nobody mentioned SWTBot or JaCoCo. WindowTester didn’t even seem to exist. Is FrogLogic still in business (Their website says, yes)?
It seemed to me that compared to last year there was almost an entirely new audience. I recognized only a handful people and 2 of them where speakers.
It think that the talks and the audience are a bit too diverse. The name “Testing Day” brings together developers people who drive test processes in larger companies, but did’t lead them to talk to one another. Instead of accepting just mixing them in a single branch of talks, the Testing Day could improve by cutting down the program for the whole audience to maybe half a day. Fill the other half day with special interest topics, i.e. bring together the developers to talk about TDD, JUnit, issues about test automation with their test runners and hard times with AspectJ. Bring the people together who want to discuss test processes in big projects, but separate these two groups for a while at least.

The organizers are aware of this, too, so I’m looking forward for a strong and interesting Eclipse Testing Day 2012.

I set up a githup repository that gives a working example for a PDE product build from a git repository. It is meant to ease the pain of setting up new builds by having a working template that just needs to be adjusted to the new project.

I’m planning a series of blog entries with and around that example. Some features are:

• Works system independent
• Executes tests
• Builds from map files
• Separates compile step and assemble step (Improves build time)
• Mostly self-contained (Required: An Eclipse SDK and Git)

How to get it running in short:

• Fetch from git://github.com/mkempka/hyperbola-pde-build-demo.git
• Adjust values in org.eclipsercp.hyperbola.releng/custom.properties
• Execute org.eclipsercp.hyperbola.releng/build.xml with ant

Here are my slides from my talk at the Eclipse Testing Day 2011 that include some documentation. I’ll do more documentation in separate blog entries the next weeks.