Eclipse sure has made a splash over the years. In celebration of the 10th anniversary of Eclipse, I pulled all the Eclipse splash screens from Git and put them all here (I skipped a few when there were only minor updates to the copyrights, etc…).
Trick or Treat!
Just in time for Halloween the Eclipse and Equinox teams have a treat for all you IDE enthusiasts… Eclipse Juno Milestone 3. The transition to Git initially slowed some of us down, but the development teams have picked up speed now. There are lots of new things in M3 to test out.
OSGi now has a new console. It uses the Apache Felix Gogo project and supports tab completion, command history, piping, grep, and a whole host of other things.
Other new features include a global debug toolbar:
And Java resource leak detection
Checkout the entire New and Noteworthy, or better yet, download Juno Milestone 3 and try it yourself.
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.
If you’re interested in the latest news on RAP, consider joining us at EclipseCon Europe next week in Ludwigsburg. There are quite a number of RAP talks this year:
On Thursday morning, Paul Petershagen of Vitaphone, a global provider of solutions in the telemedicine sector, will share their experience with a large RAP/RCP single-sourcing project. This is an good example of the power of single-sourcing. Paul also has some insights and figures from the project manager’s perspective.
Later that day, Frank Appel, one of our project pioneers, and me will show how RAP now supports the development of lightweight, modular, and dynamic web applications based on OSGi. This talk is 30 minutes so will not go into too much technical detail – instead, we’ll show some cool examples and explain the new possibilities.
For those who want to understand the technical side better and try out the new features right away, we offer a 1.5 hours hands-on tutorial on Friday. In this tutorial, we’ll show how to create and structure your RAP project, and also how to build and deploy it using tycho. Frank, Rüdiger, Holger, and me will be around so you will have first-class support. By the way, did you know that RAP finally supports clustering? If you have specific questions about this feature, Friday is your chance to meet Rüdiger, who has been working on this stuff over the last months.
And, last but not least, we are happy that another Eclipse project has decided to build on RAP: the Scout project provides a framework for rapid development of complete enterprise applications. With the upcoming Juno release, Scout will provide a RAP integration. Project leads Matthias Zimmermann and Andreas Hoegger will present “the best of both worlds” on Thursday afternoon.
You will always find one of us at the EclipseSource booth. I hope to meet you in Ludwigsburg!
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:
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:
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 the previous Effective Mockito post we saw how to use the @Mock Annotation to get a clean test. In this post I want to show you how to use Mockito’s spy mechanism to eliminate testing troubles with third party libraries.
Testing is one of the most important things in software development. I assume you agree with me because you decided to read this blog post 
. It goes without saying that when we develop software we often rely on third party functionality. This does not affect our testing because we can mock objects from third party libraries thanks to Mockito. But there is one thing that always ruins my karma…
That is, static methods. And even worse, static methods that depend on runtime state. I know there are solutions like PowerMock to enable mocking statics, but I think there is a more elegant solution to avoid the troubles with statics - without manipulating the bytecode and without adding another mocking library, as we would with PowerMock.
Let’s dive into an example to see how. First, take a look at our third party code. In this example I know that I will have to use a static method from the framework which exists in the class FancyFrameworkUtil. The only purpose of this code is to show you that I have to use it and that the third party library changes its return type magically at runtime as the comment says (this sort of thing happens way too often).
public class FancyFrameworkUtil { public static String getProperty() { return "some runtime property"; // this property changes at runtime ;) } }
Let’s get to the code we want to write: a highly sophisticated type called MyObject . This type has only one method called isPropertySet which will become API (by this I mean the method will be added to a public interface). The method only checks to see if the value of the third party’s framework has a specific value and returns a boolean depending on the value.
public class MyObject { public boolean isPropertySet() { String property = FancyFrameworkUtil.getProperty(); boolean result = true; if( property.equals( "some runtime property" ) ) { result = false; } return result; } }
We now know that the framework method returns a value that can change at runtime but this does not mean we can’t write a test.
public class MyObjectTest { private MyObject objectUnderTest; @Before public void setUp() { objectUnderTest = new MyObject(); } @Test public void testIsPropertySet() { assertFalse( objectUnderTest.isPropertySet() ); } }
As you can see it’s a very straightforward test. But it’s not complete because we haven’t tested what happens when the framework’s property value changes. We can’t be sure if our MyObject#isPropertySet ever returns true. I’m sure you’ve had a similar problem in the past, too.
At this point we have a choice. Introduce another framework to mock the static framework method or do something like the following. First, we need to extract the call to the third party library in a separate method in our MyObject implementation. It’s important that we change the visibility of this method to package private. This is the price we have to pay. But I don’t think its a high price because this method will not become API and is only visible in the implementation’s package. By separating the interface and the implementation into different packages this really isn’t a problem.
public class MyObject { public boolean isPropertySet() { String property = getProperty(); boolean result = true; if( property.equals( "some runtime property" ) ) { result = false; } return result; } String getProperty() { return FancyFrameworkUtil.getProperty(); } }
This is all we have to do to our implementation to enable the “pseudo mocking” of the FancyFrameworkUtil‘s method. Now comes the testing, and at this point we can use a spy. A spy is a real object with one or many mocked methods. Therefore we can spy on our objectUnderTest. In our case we want to mock the getProperty method that was added last. It can look like this.
public class MyObjectTest { private MyObject objectUnderTest; @Before public void setUp() { objectUnderTest = spy( new MyObject() ); } @Test public void testIsPropertySet() { doReturn( "some runtime property" ).when( objectUnderTest ).getProperty(); assertFalse( objectUnderTest.isPropertySet() ); } @Test public void testIsPropertySetWhenPropertyChanged() { doReturn( "foo" ).when( objectUnderTest ).getProperty(); assertTrue( objectUnderTest.isPropertySet() ); } }
As you can see in the test methods, the spying in the setUp method enables us to change the return value of the framework’s method by introducing a delegation step. With this we can ensure that our method isPropertySet reacts to changes in the framework’s property.
I hope it’s now clear how to use a spy to mock static framework methods by using delegation steps. If you know alternative ways, please take a minute to share it with us in a comment. By the way, there is also an @Spy Annotation you can use. Have fun spying
Read the other Effective Mockito posts:
(18) (4) (120) (57) (8) (54) (119) (35) (8) (10) (17) (10) (12) (7) (14) (3) (20) (5)