For some time now, I’ve been using Eclipse with the Flex Builder plug-in to code my Java/Flex projects. Recently I’ve decided to switch from Flex Builder 3 to Flash Builder 4. And since Eclipse Galileo had just been released, I just had to add it to the migration stack and let go of good ol’ Ganymede.

Installing Eclipse Galileo

As usual, installing Eclipse is a breeze. Go to the downloads page, select the package that suits you best, download it, then decompress it. I’ve taken the Java EE package for Mac OS X (Carbon), since it suits best my needs and the platform I’m running on (Mac OS X Leopard 10.5.7).

Installing Flash Builder 4

Download it from the Flash Builder 4 page from Adobe Labs.

Installing Flash Builder 4

Everything went smooth and after the installation was done, I was able to create my first FB4 project :

My first FB4 project

Other plug-ins

After FB4, I did install other plug-ins that I use in my daily work : the Perforce plug-in, M2Eclipse, the TestNG plug-in, JBoss Tools, EclEmma, the PMD plug-in, the Checkstyle plug-in and Flex Formatter.

Everything works fine, just as before, and I’m very pleased about it.

Migrating the workspace

The real test for my new IDE stack was migrating the workspaces I use. After everything was in place, I opened my latest workspace with my new Eclipse and it turned out to be OK. I didn’t experience any issues with the Java projects or the plug-ins.

Migrating Flex projects

Everything worked out smoothly, except for the Flex projects. When building the Flex projects from my workspace, I kept running into an error with a message like this :

Attempted to beginRule: R/, does not match outer scope rule: P/my.project

This error would pop up during each project build, so I had to do something about. I did a bit of googling and it turned out that this message is common to multiple issues to Eclipse, most of them who got fixed, so that didn’t help me much. I tried out a couple of workarounds and in the end I managed to fix the problem by deleting the Flex projects from the workspace (but not the project contents) and then using the Import wizard to recreate them :

Import the Flex project as an existing project

After I did this I didn’t receive any more errors when building the projects. However, I did change the default Flex SDK to be Flex SDK 3.4, instead of 4.0 as Flash Builder defaults to. This was the last configuration I had to do before I could work as smoothly as I did before with the Eclipse Ganymede/Flex Builder 3 stack.

A part of our team’s “definition of done” is having unit-tests in place and, unofficially, a minimum of 80% code coverage. Our Maven-based build process runs the tests and then creates code coverage reports in HTML format, that we can then consult in the documentation that Maven generates. Along with other reports, this helps us get a clear picture of where our code is in terms of stability and quality.

This is all great ; but when you’re in the middle of a task and you write unit-tests, it’s quite tedious to run the build and then open the HTML coverage report just to monitor your code coverage. I spend about 80% of my time for a task in Eclipse : opening and activating tasks with Mylyn, coding, writing unit-tests, running unit-tests and so on. This is why for me it made sense to seek out a way to monitor the code coverage in Eclipse.

After a bit of googling, I found a Java code coverage plug-in for Eclipse : EclEmma. As you can see from its name, it’s based on the EMMA Java code coverage tool. Here’s a list with its main features :

• a coverage mode in which applications launched or unit tests are instrumented and measured
• coverage overview : a coverage view containing a report on the source code coverage values at project-level, package-level and class-level
• source highlighting in the Java code editor using customizable colors
• customizable coverage counters
• multiple coverage sessions and session merging
• importing EMMA coverage data files
• exporting to EMMA coverage data, XML and HTML

The easiest way to install it is through the update site : http://update.eclemma.org. After the installation, you will notice a new launch mode appearing in the Eclipse toolbar, called Coverage, similar to the Run and Debug modes. This new mode allows you to run coverage reports on applications or unit-tests just like you would before run those applications or unit-tests.

In a project I’m currently working on, our server-side unit tests are written using TestNG. From Eclipse, I can run one or multiple TestNG units using the Eclipse TestNG plug-in, so I can easily verify that my code passes the unit tests. I have defined a launch configuration for each server-side project which runs all of the unit-tests. To check out the code coverage for those tests, all I have to do is create a coverage configuration and make sure that I select the source code folders to be instrumented.

I created a sample Java-Maven-TestNG project and added to it a simple class called ShoppingCartImpl along with a TestNG test class. Here’s how it looks :

Source code of a very basic shopping cart

As you can see, this is a very basic class. Now on to configuring the coverage settings ; this is a simple matter of clicking on the Coverage button in Eclipse’s toolbar and selecting the menu option Coverage Configurations…. This opens up the coverage configuration window, as seen below :

Creating a new EclEmma coverage configuration

All I have to do is select the TestNG test suite that I want to run and check the source folders that are relevant to code coverage. I’m using Maven and all my source code is in src/main/java so I only select that folder. I click Apply and then I can finally run the coverage report. I click on the Coverage button and theTestNG configuration is executed and the coverage report is available :

Code coverage report after a first run

In the bottom of the Eclipse window, you get a clear picture of the code coverage. As you can see, the are reports at project, package and class level, which also show up in the package explorer, in the left. To enable the decorators in the package explorer, go to the Eclipse menu and select Preferences -> General -> Appearance -> Label decorations, then make sure that the Java Code Coverage label decoration option is checked.

Another interesting feature of EclEmma is that after the code coverage instrumentation you can actually see the coverage in the source code. As you can see, each line relevant to the coverage report is marked with a color. Green is for 100% branch coverage, yellow is for some branch coverage and red for no coverage at all. The shopping cart has quite a low code coverage so I did shape it up. After a bit of fiddling with the code, I get a 100% code coverage and a very nice report :

The ShoppingCart class with 100% code coverage

I use the Flex Builder plug-in on top of Eclipse for Flex development . When it comes to coding in Flex, I often find myself missing all of those subtle but priceless options that Eclipse’s Java editor has, like the code formatting, code templates, commenting style or the all-mighty “Save Actions” option which automatically performs specific actions whenever you save your code.

I’ve recently started working on a project with an existing codebase, out of which 90% is Flex code. Facing the possibility of applying our team’s coding guidelines to countless lines of Flex code that I would have to modify, I turned to my browser and began a frantic search for something that would help. I came across a small project aiming to provide exactly what I needed : Flex formatting options. The project is called Flex Formatter and it can be found at  http://sourceforge.net/projects/flexformatter/ on good ol’ Sourceforge. It provides a set of formatting options for ActionScript and MXML code which may cover some of the common needs of any Flex developer out there.

To install it, I downloaded the latest version (0.6.7 at the time of this writing) from Sourceforge, in the form of a jar file. I copied the jar in Eclipse’s plugins folder and restarted Eclipse.

After restarting Eclipse, a new item called Flex Formatting appeared in Eclipse’s Preferences window, with options for ActionScript and MXML indenting and code formatting. I found particularly useful the indentation and the text wrapping options. Once I decided on the rules I wanted, I clicked ‘Apply’ to save my changes. Back in Eclipse’s main toolbar, 2 new buttons have appeared : Format Flex code (selected lines) and Indent Flex code (selected lines). The first will apply the rules you have specified on any Flex code selection (including indentation), while the second button will only properly indent the Flex code selection.

Another interesting option of this small tool is the possibility to export the rules to a file and import them later. This can be done from the same Flex Formatting item in Eclipse’s Preferences window. Exporting & importing make it easier for team members to share their coding style options. One team member could create the rules, export them to a file and put the file on a versioning server. The rest of the team could then retrieve the file from the versioning server and import it in Eclipse.

The formatter is far from complete. In its current version (0.6.7), it lacks some options like performing the formatting on save and it could also do with a more fine-grained set of formatting options. However, after just a couple of days of using it, this tool has saved me a lot of time and energy and I think it is definitely worth using it and I would recommend it to any Flex developer. Just try it, it won’t bite. It just flexes.