Some food for the trolls

DISCLAIMER: Before you start reading this article, I have to tell you that I am an Eclipse fanboy, a contributor on several Eclipse.org projects, developer of an Eclipse RCP app, and have been developing Eclipse plug-ins since I left school. Although I try to be objective in the following article, you may feel it is too Eclipse-oriented. If this is the case, I am sorry…but Eclipse is better

RCP applications are developed exactly the same way with NetBeans or Eclipse

Most of differences between Eclipse RCP and NetBeans RCP development are just in terminology. In NetBeans we speak of modules, in Eclipse, of plugins; we use the NetBeans Platform instead of Equinox, we have Matisse instead of Window Builder. We also have an extension registry with extension points on both platforms, to contribute extensions, and an RCP application is a set of provided modules/plugins + some of your own extensions.

It is the same thing; we can develop them the same way with either Netbeans or Eclipse.

Eclipse RCP vs NetBeans RCP starts with… SWT vs Swing

When getting started with RCP development, here is the main thing encountered, and this is technically the main difference between both Platforms: Netbeans uses Swing as a widget library, whereas Eclipse uses SWT. In my opinion, that’s not a big difference, but when it comes to choosing between Netbeans and Eclipse, there is a bigger impact when you start a new application or migrate a legacy one. People will probably choose the product with their favorite widget API.

This is the main technical difference, but it is really minor. In my opinion, this difference is not important enough to make a distinction.  Let’s look deeper, to see what these solutions provide as extensions and so on.

NetBeans is not an OSGi platform, but…

It provides exactly the same necessary features as what is used when developing Eclipse RCP plugins. MANIFEST has different keywords, but there are still modules (or plugins in Eclipse terminology) with their own classloaders and so on.

Additionally, there are a lot of integrations with OSGi. The NetBeans platform can run along with an OSGi container, and it can handle OSGi Bundles. For RCP development, the NetBeans platform provides all the necessary OSGi stuff RCP developers use. During his presentation, Geertjan highlighted some NetBeans OSGi integration by starting Netbeans over Equinox and loading EMF bundles in NetBeans.

NetBeans has an publisher, Eclipse has an ecosystem

That’s probabably one of the key arguments in the debate, and it has a very strong influence on both products. The entire NetBeans roadmap is piloted by Oracle which is wholly responsible for it. At Eclipse, there is no such single pilot. The Eclipse Fundation oversees Eclipse development, but there is not ONE single publisher, there are lots of contributors from different companies. Eclipse is not only modular technically, it is also modular in term of organization. There are several projects that are developed by independent groups. There might be some dependencies between them, but in the end, you have different teams developing different projects.

NetBeans is a single project developed by a company, whereas Eclipse is an amalgamation of different projects developed by a community of individuals and companies. Then…

NetBeans is homogeneous, Eclipse is heterogeneous

Eclipse developers must admit this: NetBeans is much more homogeneous than Eclipse. And this is true in several domains: UI, ergonomics, code quality (which by the way is quite good, according to NetBeans users who find it less buggy than Eclipse code). This is a plus for NetBeans since users who know how to do one task with NetBeans will easily figure out how to do another. It is pretty user-friendly, especially for users who are new to the Java IDEs world.  They can easily leverage most of the IDE and the platform; thanks to its high consistency (standardization). Thus NetBeans rapidly becomes straightforward to use and leverage.

Compared to NetBeans, Eclipse seems difficult to fully manipulate. There can be a lot of differences between 2 projects, in term of usability (creating a web project is quite different than creating a plug-in project, as you often need to learn how to do something), and also in term of quality. The Eclipse platform quality is very good, and so are most of the mature projects, but there are some others are more buggy and makes the IDE less comfortable. Also, when you reuse some code from other projects, you often have to tweak it to get it working well. For Eclipse developers like me, that’s no big deal; but for new users or for people coming from NetBeans, that can be a major issue.

and…

NetBeans has some tools, Eclipse has a lot of projects

The openness of Eclipse provides something very different from NetBeans. NetBeans is one product with different tools. Eclipse is one platform with different projects. These projects are much more numerous than NetBeans components, and they allow you to take several roads at the same time. Eclipse has a kind of wide usefulness that can handle classic IDE problems, Mobile-Development problems, Model-Driven problems, Rich Internet Application problems, and so on.

Two years ago when it was time to choose a name for the 2010 “Helios” Eclipse release, I especially liked the proposal for Hydra, because it is made of one body and several heads. This is a metaphor that fits Eclipse well. To go further with the Hydra comparison, it is considered to be a monster by many people, though a very powerful one…

Eclipse projects - so many, so powerful

I see in NetBeans something more under control, more cohesive, and less scattered. Great tools are provided with NetBeans (Matisse, Installer Framework, and more) to facilitate the development of RCP apps. Getting started with RCP is probably easier with NetBeans since things are more consistent, but I sense a lack of opportunity to find and reuse some very cool things from other projects – one of the great things you get used to in developing Eclipse RCPs. (I remember how tickled we were to discover and reuse the wiki capabilities of Mylyn.)

If I had to use a mythological metaphor, I think I would compare NetBeans to a Minotaur: a strong and nice-looking beast, but with only a single head

The "simpler" NetBeans: good-looking isn't everything

Although the R&D team is considered the “winner” in this success, we are very aware that there are a lot of people who have been involved in the development of Bonita Open Solution. Maybe some of them do not even know it!

So, we want to thank a lot of people who really deserve it:

• Thanks to the R&D team, who developed this product well enough to get attention from the Eclipse community.
• Thanks to the BonitaSoft officers, who are driving the product to ensure it is succeeding in the world of BPM, and that it is really democratizing BPM.
• Thanks to all the BonitaSoft employees who provide a lot of feedback and help to ensure that the product meets the expectations of day-to-day users.
• Thanks to the entire community of BonitaSoft users and contributors, who provide feedback, report bugs, and suggest new ideas. They may not be really aware enough of how much their input helps make the product better and better.
• And also thanks to the Eclipse community, and the other open-source communities we depend on, who very often solve our problems. There are lots and lots of people who helped us to develop Bonita Open Solution and even if they are not aware of it, they deserve a piece of this award.

And here it is:

This award is not only for a team or a company, it is also for a community of users and was earned because we had access to the knowledge of several communities of technical experts. Once again, a great example of how Open Source leads to great things!

What is the second thing you see when you start an Eclipse RCP product? The intro page. This page is the first interaction that the user has with your product. It deserves real effort to ensure that your users feel comfortable when opening the product. Also, you can leverage this page to add dynamic content, that can be used, for example, for direct communication between your company and your users. Then it can become a tool for both user-friendliness and marketing, with a relatively low effort. It’s worth it!

In this post we will describe how we leverage the intro page extensibility and API to develop a more ergonomic and marketing-friendly intro page. Everything you will read here can be found or taken directly from the Eclipse Help contents, but I’ll try to explain it more practically.

The intro page can also be defined using SWT, but in this post we will focus only on using (X)HTML to define intro pages, since it is more appropriate to the use case of “out-sourcing” the intro page to design or marketing.

What can you expect from your (X)HTML intro page

While using (X)HTML, you can also use JavaScript. Although most Java developers are not fond of JavaScript, we must admit that it is a very powerful language when it comes to playing with the content of a web page. JavaScript makes your page dynamic, and is something that most web-oriented people can tweak to create nice effects on your page (feedback, images in a carousel, powerful widgets…).

You also can expect 2-way communication between your intro page and your application:

That means that you’ll be able to trigger actions in your application from your intro page, for instance to create a new file, or open a wizard, or anything your application can do.

And you can also populate your page with data coming from your application. A use-case we chose for Bonita Studio is to show the “Recently opened” files on the intro page. This requires the page to look at the files in the workspace and show the ones last modified. We also use it to show the content of some RSS streams.

With all this stuff, you can create a highly dynamic page well integrated into your application! Here is a video of what we’ve got for the current release of Bonita Open Solution – 5.4.1:

Here is the recipe:

Define an intro for your product

This step is just about overriding the default Eclipse intro page for your product and defining contents for the intro. Since we want the intro page to be easily maintained by the design and marketing teams, we chose to use XHTML to define it. XHTML is much more accessible than Java and SWT for them . In this post, we will only focus only on using HTML or XHTML, skipping SWT.

In one of your plugin.xml files (for instance in the plugin that contains your html page), add:

This means that for org.bonitasoft.studio.product, you’ll show the intro as defined in content/introContent.xml, starting from the page with id root, in html mode (you can use swt if you want).

As you can see, this extension binds an introContent.xml file to your product. Now, add it to your bundle, along with the html file of the page. Note that the page that will be displayed as intro is the one with id root:

Intro plugin tree, and introContent.xml

Contents of the file

XHTML or HTML

In your introContent.xml, you have 2 ways to reference the file you want to show, depending on the attribute you use to locate the page in the page element of introContent.xml:

url=”myPage.html”

With a url, you will be able to show any HTML or JavaScript you want. Everything will be simply displayed in a web browser. You’ll be able to call some of your application code by clicking links. (See “Links to actions in your application”), however you won’t be able to add contents to that page at runtime depending on your application state. This method is preferable when you don’t need to fill the page with data from your application, since it provides full support for JavaScript.

content=”myPage.html”

The content of your HTML must be valid XHTML. Thus your file can have the same content as any HTML file, except that it has to start with the XHTML header (<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”> <html xmlns=”http://www.w3.org/1999/xhtml”>) and all your tags must be closed. If you are generally using Java, you probably often edit XML, then nothing shocking here. (By the way, I do not understand why XHTML is not the de facto standard nowadays…)

Your file must conform to the W3C specification. The W3C validator is very helpful while debugging it.

Since your XHTML intro page will be displayed in the internal Browser of Eclipse, there is obviously support for JavaScript! Except if you use contentProviders in your page, you have to use the content XML attribute in your introConent.xml instead of the url attribute, and there is currently a limitation for JavaScript support that is reported on bug 332416, that makes impossible to execute JS code that contains “<” or “&”, and possibly others.

However, only the content mode allows you to use contentProviders.

Links to actions in your application

This is well described in the Eclipse help, and is pretty easy to set up. For each action you want to call from your intro page, implement your action as a class that extends IIntroAction. Then, whenever the internal intro web browser reaches the URL http://org.eclipse.ui.intro/runAction?pluginId=org.bonitasoft.studio.intro&amp;class=org.bonitasoft.studio.intro.actions.NewProcessAction, the NewProcessAction will be executed.

Then simply add links from your HTML page to your actions:

Content depending on your application state (contentProvider)

This only works when you reference your page using the content attribute, in your introConfig.xml. The official documentation is here.

The key is to create a class that implements IIntroXHTMLContentProvider. With XHTML, it is generally more comfortable to implement the createContent(String id, Element parent) method. Here is the content provider we use for internationalization of messages in our intro page:

And then, we can include a message from our NLS messages class in the XHTML page using:

Examples

All this stuff, and much more, can be found in our SVN repo. You’ll hopefully find some clues and ideas if you’re stuck

Our build still uses the highly customized headless PDE-build wrapped in a master script responsible for packaging and testing the application as we deliver it. Here are the steps we followed:

Create the feature from the product definition

This was not a trivial task, since there is no tool to transform a product definition to a feature. The solution we chose was to use Run Configuration to  create the feature. This is an intermediate step that is useful to turn a product definition into a feature:

• Right-click on your *.product, and Run as Eclipse application
• The Run Configuration matching the definition of your .product (and then the set of plugins that it contains) is created
• Create a new feature, and use the magic Create from Run Configuration button
• Remove the launchers (org.eclipse.equinox.launcher*) from this feature

This method is inspired from blog posts written by Manuel Selva.

Redefine your *.product

From there, you can redefine your .product to include only 2 features: the one you just created, and the org.eclipse.rcp feature.

Quickly validate it

You can make a first validation of your product. The steps are easy:

• Create a launch configuration for your product by clicking on the Run As Eclipse application or the Synchronize entry
  

  Launch product from product editor

• Open the launch configuration wizard, and click on the validate button
  

  The validate button will give you some hints to fix deps

• It tells you about some static missing dependencies. Correct your feature according to its advices.
• Be patient and keep retrying when you get errors. I think I needed more than a dozen iterations before getting the happy button telling me all is well.

Add the feature to your map

This step is only mandatory if you have a headless build that uses map files. If you usually build using UI, just skip it.

Happy HEADLESS Halloween !

Everything is in the title: you just created a new feature, and you’ll need it at build time. Simply add an entry for the feature to your map:

Try, see and troubleshoot

Once you’ve done all that, try to build your product. Using the UI entry should be enough.

The export product wizard

Fixing startup

After that, you can give a first try to your bundled product. Run it. It may fail to start. In this case, analyze the startup log that you will find in YourProduct/config/[timestamp].log. You’ll probably see some lines such as these:

This simply tells you the missing bundles in your feature. Then, for each Missing required bundle entry, you will need to add it to your feature, take a look at its dependency tree, add some its dependencies if you missed them, and… Retry !

Fixing runtime

It can easily happen that one of your plugins does not start without crashing the whole product. In such case, you silently lose the features provided by the code of your plugin. Then you can use the OSGi console to get insight about what’s going wrong.

In this example, the log tells me that it cannot load the test plugin, but I don’t really know why. So I can try the following:

Thanks to the console, I can figure out that the missing bundle is org.hamcrest library. I just add it to my feature, and everything works better. Using the console is a general method to resolve dependencies issues. The console is often your best friend!

Conclusion

As you can see, switching from a plugins-based product to a feature-based is not immediate. Features do not provide the fantasically useful Add Required Plug-ins button that you can find on a plugin-based product, and so this move will probably lead to errors in dependency management.

The "Add Required Plug-ins" button is only available for plugin-based products

That’s why, once you have your feature, you need to tweak it to get your product working, since you can easily miss a bundle. Moreover, the bundles you ship may have a different version after a feature-based build. You’ll need to test it well to ensure that this move did not break some features of your product because of bundle versioning. I opened bugs 328323 and 319085 to ask for improvments on this topic.

As always, automated non-regression tests are your very best friend for such a move.

Our feature-based build has now been working for a few days, and I can already tell I am quite happy with it. The build of our 2 products is easier to understand and maintain, and now looks like a simple composition of features. Also, adding a language does not require us to modify the .product any more, and it helps us to get closer to the ability to provide “language packs” as extensions of the product.

Next step, moving to p2…but that will be another story!

By the way…

Aurélien and I will be at Eclipse Summit in Ludwigsburg. Aurélien will have the opportunity to present to the Eclipse community how we leverage the Modeling projects in our product.
If you want to have a chat with us, about anything, feel free to drop us an email to plan a meeting, or grab us during the event!

A few days ago, I had to fix a bug on the 5.2.3 branch version of the Studio/RCP part of Bonita Open Solution. The classes I needed to modify had been strongly refactored in trunk (5.3), so that the fix would be different on the trunk than on the branch, and it was impossible to simply propagate a fix.

So I had to edit old code. But my workspace only contained trunk code, and the old code was not compiling because of several refactorings. I was wondering how the heck I would be able to easily work on code from the past…!
But I found an answer and it’s simple… TARGET PLATFORMS !

Here is what I suggest to isolate the branch fix from trunk development:

1. Create a new workspace (workspaceBranch).
2. Set the old version of your product (here the 5.2.2 version) as the target platform. This must be the version containing the bug.
   

   The target platform is made up of all bundles of the product containing the bug

3. Check out ONLY your old bugged bundle from the branch.
   

   A minimal and easy-to-use workspace

4. Create your launch configuration which is made up of the product and your buggy bundle project from workspace.
   

   Configure your launch to use your product, with the patched bundle from your workspace

5. Run and test your product to see the bug.
6. Fix your old code.
7. Test your fix.
8. Commit your fix on the branch.

With this trick, I avoided the headaches of mixing trunk and branch code. It made my work much easier and less risky.

The only annoying thing is that you lose all your workspace preferences and Mylyn contexts during the time it takes to finish the fix, so this is not critical.

I can now say it: I ♥ target platforms!

BonitaSoft presentations

On Wednesday afternoon, Charles presented a short talk in which he explained the SWT « no more handles » error and how to get rid of it. This was an error we encountered right away while developing Bonita Open Solution, and EclipseCon was an opportunity to share the knowledge we acquired as we resolved it. The presentation was dynamic, pragmatic and concrete (Charles’ style). He got some positive feedback from people who were currently struggling with handle leaks, and who learned a few tips from us. Charles’ slides are available here.

In the evening, while everyone was scarfing burgers at the reception-poster session, we presented our poster which shows how Bonita Open Solution leverages Eclipse. Since it was during dinnertime, the buffet was very busy and there were not a whole lot of people paying attention to the posters, but there were several curious people who came to discuss parts of the solution. We were able to describe the product to people according to their interest, and we had some good discussions about the power of Eclipse behind the RCP part of the solution. Some visitors also gave us some interesting ideas that may turn into upcoming features.

Bonita Open Solution poster

Modeling

Since Bonita Studio is mainly about modeling processes and forms, one of the topics we followed closely was modeling, and more specifically diagram modeling. We were very pleased that our process editor was cited by Obeo‘s Etienne Juliot as « one of the most beautiful GMF-based editors » during his talk, in which he showcased several use cases of GMF.

Another very interesting thing to keep in mind about diagram modeling is the Graphiti project. We spent some time in the Graphiti introduction talk and had an interesting discussion with Michael Wenz.  It seems that Graphiti is a real alternative to semantic-unaware GEF and generation-based GMF, since it offers a natural mapping between graphical elements and semantic models and makes customization of diagrams easier. It seems to be very useful for editors that rely on an EMF model and that are very tricky to implement with GMF generation. I personally think that it could be adapted to our form editor, if it should have to be re-written one day…

Build and continuous integration

Let’s start with the p2 tutorial of the Monday morning. Here we picked up a lot of tips about how to leverage p2 in product builds. Currently our studio does not use p2 because we were not able to merge platform-specific product distributions into a single zip, but this will be changed soon thanks to Pascal Rapicault and Kim Moir’s advice during the tutorial. I hope to tell you more about a « bundlepool » p2 director property soon, in this blog or in the Equinox newsgroup.

My favourite EclipseCon T-shirt

Another interesting thing in the Build World is the rise of Tycho, which allows you to build Eclipse plugins or OSGi bundles using Maven. This seems to be very easy to adopt and a good way of thinking:  bundles as Maven artifacts, and p2 repositories as Maven bundle repositories. There are already a lot of enthusiastic people talking about this, and it is something I’d like to try soon.

Something else that really enouraged me is the growing interest for SWTBot in the Eclipse community (1 dedicated tutorial, 1 talk, and a recurring subject in build-related talks). As you may know, we already use it extensively here for integration tests, and knowing that the community of users is growing ensures that the project will keep on improving! At EclipseCon, we spent some time with Charles and Obeo‘s Goulwen le Fur talking with Ketan Padegaonkar (SWTBot project lead) about the status of an experimental Test Recorder that you can find on the SWTBot codebase. Such a feature would be very powerful since it would allow your user to generate a TestCase simply by reproducing a scenario as you would normally with your product. This would for sure reduce test writing costs, make tests closer to real use cases and facilitate bug reports. However, according to Ketan, there is still some development work before it becomes really usable.  So, if you have the resources and the motivation, please contribute by giving it a try, asking questions on the forum and opening bugs for it!

The Hudson sticker we got in Build Panel on our IC machines

Emerging technologies: e4, RAP & Egit

We arrived at EclipseCon with some specific questions about emerging technologies, and we got our answers!

The first one is about e4: should we migrate Bonita Open Solution to e4? Why? When? Here the talk of Boris Bokowski and Paul Webster « Migrating to e4 » gave us a concrete answer. That answer is yes, we should migrate to e4, but not before other projects we use (such as GMF) have migrated to e4, and this represents a real investment of resources for us. Our conclusion is that we have still at least one year to wait…

I also attended the very good tutorial « Single Sourcing RCP and RAP applications » and spent some time speaking with some EclipseSource guys working on RAP (Benjamin Muskalla and Elias Volanakis), to find possible obstacles to port Bonita Studio to the web using RAP. We concluded that there are 2 main things that are not implemented yet in RAP that are critical for us: user-session workspace (currently there is a single workspace for the whole RAP application, whereas it would make sense to have one workspace per user), and diagramming capabilities. If you are interested in user-workspace in RAP, you can follow and comment to this thread.

And also we wanted to learn more about Git and how it interacts with Eclipse, since a lot of people have been evangelizing about it for a few months. We are currently using SVN here, and it seems that Git is not adapted to our 8-people-located-in-the-same-room R&D team organization. Indeed, the system of review-and-merge seems to be very time-consuming and not so easy to understand. However, Git becomes very interesting when the product developers/contributors are distributed all over the world and when there are lot of contributors to a product.

Other conference things

Some other talks we attended and enjoyed a lot:

• Andrew Eisenberg, Getting Groovy with Eclipse: this talk left no doubt that Groovy-Eclipse deserves its Community Award.
• Boris Bokowski, Embedding web UI components in Eclipse: learn how powerful the Eclipse web browser is!
• Phil Quitslund, UI Testing Patterns and Best Practices: A set of concrete tips to improve your tests, and a very good speaker.
• The incredibly amazing keynote of Jeff Norris! (See some descriptions)

Charles and I also took part in the EclipseCon exercise (actually only the two first days; after what we got a bit lazy). It was a very good way to start the day! Thanks to Kim for organizing it.

Something else we paticipated in was the Trivia game, and we are happy to say that we were quite successful!  I won on Monday, and Charles won on Thursday. We worked hard to win these phones, but it was fun and a great opportunity to talk with some new people.

We were very lucky with Trivia game

Other things in California

Just some pictures to share…

Amazing Stanford univerity campus

Golden Gate and the Bay

San Francisco's Lombard Street

Sharks vs Canucks

And in conclusion…

EclipseCon was great! Congrats and thanks to everyone involved in its organization!

]]> http://www.bonitasoft.org/blog/uncategorized/our-eclipsecon/feed/ 4 http://www.bonitasoft.org/blog/eclipse/swtbot-my-new-friend/ http://www.bonitasoft.org/blog/eclipse/swtbot-my-new-friend/#comments Tue, 02 Feb 2010 17:38:12 +0000 mickael.istria.eclipse http://www.bonitasoft.org/blog/?p=335 Preamble: This is the first post of the new Eclipse category of BonitaSoft’s community blog. As soon as we find something interesting to talk about when developing Bonita Studio, we will try to share what we learnt with our communities: BonitaSoft and Eclipse. We are also pleased to see this category aggregated to Planet Eclipse knowledge feed. We hope you’ll enjoy reading these posts!
The Bonita Studio developers crew

I found some time recently to take a look at SWTBot to check whether we should use it while developing Bonita Studio (part of Bonita Open Solution, based on Eclipse Gelileo 3.5.1). After a few minutes of reading wiki pages and trying it, I was convinced that SWTBot (and its GEF extension, that also works for GMF) is a must-use project for anyone who has ever it found difficult and time-consuming to write plugin tests.

Only a few hours later our continuous integration build welcomed our first SWTBot based test!

Here is the step-by-step of this awesome encounter:

1. Install SWTBot on your development platform by installing SWTBot from updatesite: http://download.eclipse.org/technology/swtbot/galileo/dev-build/update-site
   
2. Create a new plugin to host your test. Add these dependencies to your plugin.
3. Write your test

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

   package org.bonitasoft.diagram.test; import org.bonitasoft.studio.model.process.diagram.part.ProcessDiagramEditor; import org.eclipse.swtbot.eclipse.finder.widgets.SWTBotEditor; import org.eclipse.swtbot.eclipse.gef.finder.SWTBotGefTestCase; import org.eclipse.swtbot.swt.finder.junit.SWTBotJunit4ClassRunner; import org.eclipse.swtbot.swt.finder.widgets.SWTBotMenu; import org.eclipse.ui.IEditorPart; import org.junit.Assert; import org.junit.Test; import org.junit.runner.RunWith; /** * @author Mickael Istria * */ @RunWith(SWTBotJunit4ClassRunner.class) public class DiagramTests extends SWTBotGefTestCase { @Test public void testDiagramTest() throws Exception { SWTBotMenu menu = bot.menu("Process"); menu.menu("New").click(); // simulate a click on Process > New menu entry SWTBotEditor botEditor = bot.activeEditor(); IEditorPart editor = botEditor.getReference().getEditor(false); Assert.assertTrue("New process should open a process editor", editor instanceof ProcessDiagramEditor); } }

4. Configure your test run
   
   1. Use JUnit4 as launcher, and don’t use UIThread (SWTBot tests won’t run in a UIThread)
      
   2. Set the product you want to test (leave default org.eclipse.platform.ide for “simple” plugins)
      
   3. Increase memory and set a language
      
5. Run and enjoy the high code coverage that you get with so few lines of code!
6. Ok, now let’s try the GEF extension of SWTBot to check some tricky behavior in a diagram editor. This test creates a new process and then activates a tool in the design palette to create a new step, and then does some checks (and all in about a dozen lines :

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

   @RunWith(SWTBotJunit4ClassRunner.class) public class DiagramTests extends SWTBotGefTestCase { @Test public void testDiagramTest() throws ExecutionException { SWTBotMenu menu = bot.menu("Process"); menu.menu("New").click(); SWTBotEditor botEditor = bot.activeEditor(); SWTBotGefEditor gmfEditor = bot.gefEditor(botEditor.getTitle()); gmfEditor.activateTool("Step"); gmfEditor.mouseMoveLeftClick(200, 200); menu.menu("Save").click(); IGraphicalEditPart part = (IGraphicalEditPart)gmfEditor.mainEditPart().part(); MainProcess model = (MainProcess)part.resolveSemanticElement(); Pool pool = (Pool)model.getElements().get(0); Assert.assertEquals("Pool should contain 3 nodes", 3, pool.getElements().size()); } }

7. Run again, and enjoy even more: SWTBot for GEF provides a lot of very high-level Methods to manipulate your diagram. Without it, writing tests for a GMF based editor was quite difficult, and did not mimic user actions very well. With this, you can test real usage scenarios with very little code.
8. The return on investment with SWTBot looks very good, so let’s adopt it and automate test execution in a continuous integration build, leveraging the SWTBot headless framework. The following requires you to be familiar with automated PDE or RCP build and testing.
   1. Install swtbot in the platform you use to build your plugins or your RCP app. For instance, you can use the P2 director commandline application to install it from updatesite:
      java -jar plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar -application org.eclipse.equinox.p2.director -artifactRepository http://download.eclipse.org/technology/swtbot/galileo/dev-build/update-site -metadataRepository http://download.eclipse.org/technology/swtbot/galileo/dev-build/update-site -installIU org.eclipse.swtbot.eclipse.feature.group -installIU org.eclipse.swtbot.eclipse.gef.feature.group -consoleLog
   2. Install SWTBot headless test framework in your build platform: Download it from SWTBot download page, and expand it in your build platform directory.
   3. Add the SWTBot runtime and headless plugins and your new test plugin to your test feature.
      
      In our case, we prefered keeping only the org.eclipse.ant.optional.junit fragment and using new junit bundles to avoid conflicts between classes from org.junit and org.junit4 bundles. However, SWTBot provides some alternative fragments to support either junit3 or junit4 if you prefer.You can add the following entries in your map file for new junit bundles:
      !** Use newer JUnit as described in http://wiki.eclipse.org/Eclipse/Testing/JUnit4_Changes
      !** Should facilitate integration with SWTBot headless
      plugin@org.junit,4.8.1=GET,http://download.eclipse.org/tools/orbit/downloads/drops/S20100120144102/bundles/org.junit_4.8.1.v4_8_1_v20100114-1600.zip,unpack=true
      plugin@org.junit4=v20100104,:pserver:anonymous:@dev.eclipse.org:/cvsroot/eclipse,,org.junit4
      plugin@org.eclipse.jdt.junit.runtime=v20091201-0800,:pserver:anonymous:@dev.eclipse.org:/cvsroot/eclipse,,org.eclipse.jdt.junit.runtime
   4. In the piece of script that runs your test, add the following test invocation command:

      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

      <echo>SWTBot test</echo> <java dir="${eclipse.test.home}" fork="true" output="${eclipse.test.home}/output.txt" logError="true" classname="org.eclipse.core.launcher.Main" failonerror="false"> <classpath> <fileset dir="${eclipse.test.home}/plugins"> <include name="org.eclipse.equinox.launcher_*.jar"/> </fileset> </classpath> <arg line="-application org.eclipse.swtbot.eclipse.junit4.headless.swtbottestapplication"/> <arg line="-testPluginName org.bonitasoft.studio.diagram.test"/> <arg line="-testApplication org.bonitasoft.studio.application.application"/> <arg line="-className org.bonitasoft.studio.diagram.test.DiagramTests"/> <arg line="formatter=org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormatter,junit-results.xml"/> <arg line="-nl fr"/> <arg line="-consoleLog"/> <jvmarg line="-Xms40m -Xmx348m -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError"/> </java>

9. At this point, when everything is working, you should be one of the happiest people in the world: You have not only reduced the difficulty and cost of writing tests, but also increased the coverage and the realism of your tests

Congrats and thanks to SWTBot developers for making this possible! We love playing with it when developing Bonita Open Solution!

If someone has a better solution for this integration, please tell me!