Friday, July 13, 2012

What will Maven do?

As much as Maven makes it easy to deal with builds, the plethora of XML and the varying life cycles phases can sometimes make it hard to figure out what a build will actually do.

To help with this, I'm happy to make available the Eclipse plugin called the "Maven Inspector". This plugin provides a simple View called "Maven Execution" that presents for a given POM file the phases and associated MOJOs.


Tuesday, May 29, 2012

Eclipse-based applications as standard mac application bundle

It's not every day that a 5 digits bug number get's fixed in Eclipse*, so I'm happy to report that the long standing bug 57349 is now fixed in Juno (Eclipse 3.8 / 4.2). It means that you can now deliver eclipse-based applications as mac os x bundled applications.

New layout

For an end user, the biggest change brought here is that the application is now an opaque entity and it has an icon. See screenshot below of the same application to compare.

Now in the details, the new layout pictured on the left mainly differs from the legacy one on the right by two things:
  • the top level folder is now suffixed with .app; thus making the application an opaque entity that requires a special user action to navigate into it (this is also why the left picture does not show the top level folder)
  • the actual launcher included in the Contents folder is included as a child of the top level folder where as in the past it was in a folder whose name was the name of the launcher (e.g. myRCP in the example).

How do you enable this new layout?

  1. Make sure the application you are building uses p2 included in Juno
  2. Move your build environment to use PDE Build from Juno, or Tycho 0.15.
       This will cause the additional metadata necessary to support this new layout to be generated.
  3. When you invoke the p2.director (the one from Juno) to create your application simply suffix the install folder with .app and let the magic happen. If you don't want to keep the legacy shape, don't use the .app suffix. Here is an example of command line: ./eclipse -application org.eclipse.equinox.p2.director -installIU <iufortheproduct> -destination Applications/ -profile <somename> -repository <therepotoinstalltheproductfrom>

Note to tycho users

Tycho 0.15 (still in snapshot at the time of writing this post) generates the appropriate metadata and p2 repo, but the support to create an installation and archive with the correct layout is not yet released (bug 378021). To obtain the desired shape you can either call the p2 director as mentioned above, or use the workaround provided in bug 378021.

Note to PDE build users

PDE build generates the appropriate metadata and p2 repo, but it will not create an installation and archive with the correct layout. To obtain the desired shape you will have to manually invoke the p2 director as indicated above.

And to conclude I would like to mention that this work has been sponsored by Manumitting Technologies. * Well actually, at this point I count 28 5 digits bug number fixed in Juno and one 4 digits bug number - bug 9503

Monday, May 28, 2012

Running tycho tests on multiple machines

Recently I ran into a situation where I wanted to run the tests of an RCP application on different machines. Obviously, the simplest solution consists in running the full build on each machines. This means that every bundle and test bundle will be compiled on each machine, and the tests executed on each machine.

Of course, this works. However I'm not a fan of this approach because I like to test what I ship. What I'm getting at is that when the code is compiled on different machines, there is a chance that different binaries can be produced, which means that from a purist point of view the testing done is invalid since you have not tested the binaries that are finding their way into the final distribution of the product.

What I'm describing below is a way to structure the build that allows:
  • tests to be executed on multiple machines without recompiling the tested code;
  • developers to keep on running mvn clean install and get the code to compile and the tests to run;
  • developers to have minimal understanding of the overall build setup to add a bundle and its tests.

First, let's review the relevant modules of the setup:
  • code : bundle that needs to be tested
  • test : bundle that contains the tests
  • repo : p2 repository containing the bundles being built
  • allTests : parent and aggregator that build and execute the tests
  • parent : main parent and aggregator for the build that includes code, repo and allTests.
The main idea behind this setup is that it provides two main entry points. One that allows for the complete build to run and a second one that just executes the tests. With these abilities it becomes very easy to create a setup where:
  • a main build machine would run a complete build and publish the p2 repository to a shared drive or a repository manager. This is done by executing mvn clean install in top level aggregator here called parent;
  • multiple test machines would be configured to just execute the tests and obtain the artifacts to tests from the repository created by the main build. This is done by executing mvn clean install -DtestedRepo=<pathtorepo>
  • the coordination between the main build and the tests would be done using a CI.

The repo used to obtain the artifacts needs to be setup when the test build is run. In case of a full build, we don't want this repo to be used since it could cause interference. Therefore, the repository is defined in a test specific profile, in the allTests aggregator that also becomes the parent of all the tests projects.
Rather than requesting the activation of the profile and passing the repository parameter, this profile is only activated when the testedRepo property is set.

Et voila, it is that simple. This approach also has the following additional benefits:
  • catch errors early without wasting multiple build executors since the main build will first run to completion by executing the tests;
  • potential build time reduction, if download jars from a repository is faster than building them.
The complete code for this example can be found at

Thursday, April 05, 2012

Sharing your plug-ins easy as 1-2-3

"Hey, this is a cool plug-in, where did you get it from?" is a question that I hear quite often and to which the answers most people provide are a google search, a vague reference to the eclipse market place, or a lengthy email with links to p2 repos and sentences to explain which element should be selected. With any of these solutions there is a lot place for errors, especially if you are trying to have the same version.

Since Indigo, p2 provides the ability to answer this question in 3 easy steps using the import / export functionality. Let's see how this works

Step 1 - Create a description file

Using the File > Export > Install > "Installed Software Items to File" wizard, select the plug-ins that you want to share, and save these to a description file.
In the screenshot below I've decided to share both the Groovy for Eclipse plugin and the Remote System Explorer plugin.

Step 2 - Share the description file 

The description file created, share it using your favourite social media, or just simply email.

Step 3 - Import the description file 

Upon reception of the description file, go to File > Import > Install > "Install Software Items from File" wizard, pick the file to install from and just follow the steps. You may also want to uncheck the "install latest version of selected software". This will cause the selected items to be installed from the remote location.


This showed how easy it is to share details of your install with others. It works well for ad-hoc sharing. For anything more complex like keeping in sync all the members of a team, I would instead recommend the usage of Yoxos from EclipseSource (I am *not* affiliated with EclipseSource) that offers a solution dedicated to solving this problem.