Shared installs just got better!

For many years, shared installs have been a second class citizen to p2. Thanks to the sponsoring of Ericsson, I'm happy to announce that some of the most annoying bugs have been addressed in Eclipse Kepler starting at M6.

First and foremost, when changes are being made to a read-only Eclipse install, the plug-ins that have been installed by the user no longer vanish mysteriously leaving the workbench with a sea of red square icons (the sign that something went wrong).
Instead, on startup, the user is automatically presented with a migration wizard giving the opportunity to re-install these plug-ins. Should the user not be interested in migrating, a confirmation dialog shown upon cancellation gives the ability to delay the migration to a subsequent restart or completely ignore it.
 

Building on this support, we've also decided to assist users in re-importing their plug-ins from a previous read-only installation. The reason is simple, many corporations chose to deploy new versions of Eclipse in different folders. This is required to give teams the ability to adopt Eclipse at their own pace, but it also means that when users start using a new Eclipse install, they need to re-install the plug-ins they had installed on their own. Of course users could use the import/export feature provided by p2, but the time wasted by the user wondering why the plug-ins have vanished and then figuring out what to re-install can be significant, which is why in such situation we are also presenting the migration wizard.

We are feeling pretty good about those changes and hope you'll enjoy them. To give it a try, go and download the freshly new released M6 build of Eclipse SDK.


Update - What is a shared install? Eclipse is said to run in shared-install mode when the Eclipse installation folder is read-only. This situation happens when Eclipse is installed in C:\Program Files, or when it is installed by a package manager.
In such cases, when the user executes Eclipse a folder is created in the user home that stores all the configuration information as well as the plug-ins installed by the user.

The Eclipse Platform builds moved to Tycho, help wanted

Earlier Today, the Eclipse Platform team announced [1] that from now on, the official builds of the Eclipse Platform will be exclusively produced using Tycho instead of PDE Build.
This is a major milestone in the life of the project considering that it has been using and evolving PDE build for over 10 years. This conversion from PDE Build to Tycho has been months in the making and required non trivial work from many people. Congrats to everybody involved!

Why this switch? To make it easier for a wider audience to build the Platform (see instructions), and more generally to align the Platform build with the rest of the Eclipse Ecosystem that is "standardizing" around Tycho (this is also being referred to as the common build infrastructure aka CBI).

Though the team feels confident that things are in a working state, it is highly suggested that you try out those builds to help us find any remaining issue that could have slipped in. To that end, just pick any I build from http://download.eclipse.org/eclipse/downloads/ and report your bugs.

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.

Go check it out on http://prapicault.github.com/MavenInspector/ or directly install it from http://prapicault.github.com/MavenInspector/repository

Enjoy!

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/myCool.app -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

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.

Details:
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 https://bitbucket.org/prapicault/tycho-tests-multiple-machines.

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.

Conclusion

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.

Montreal demo camp next week

The Montreal demo camp will be on next Tuesday, Nov 29th! Don't forget to register and propose a session as there are still many spots available.

See you there.