Selecting Plug-in Versions in a Headless Product Build

As Pascal likes to say: "PDE.Build is an onion." Don't be afraid to reach in and savor those inner layers. Here is an example:

We support building from a .product file. Generally, people base their product files on a list of plug-ins. There is currently no way to specify plug-in versions in the product file. If you have a requirement on a specific version of some bundle and for some reason there are multiple versions in your target, then you may be stuck with pde.build choosing the wrong version for you.

In a product build, a container feature is generated based on the contents of the .product file and the build is run using this generated feature. Features can specify the versions of the plug-ins they want to include, or they can specify "0.0.0" which means any version. They can also specify a version like "3.2.1.qualifier" which means any version starting with "3.2.1". (Though beware of this bug). The generated feature simply specifies "0.0.0" for each plug-in from the .product file.

PDE.Build provides an eclipse.idReplacer ant task. It uses this task to replace versions in the feature.xml with the actual versions that are built. It is easy to imagine using this task to modify the generated feature.xml to specify the plug-in versions you want before fetching or generating scripts.

In your customTarges.xml preFetch (or preGenerate) task, do something like this:

 <eclipse.idReplacer
    featureFilePath="${buildDirectory}/features/org.eclipse.pde.build.container.feature/feature.xml"
    selfVersion="1.0.0"
    featureIds=""
    pluginIds="org.eclipse.foo:0.0.0,1.3.0.qualifier,org.bar:0.0.0,3.2.0.qualifier," />

Beware of this bug in 3.3.0, and this bug in 3.3.1.

Eclipse launcher is losing its head

The Eclipse launcher has always required a graphics library (ie GTK, Motif) to show error messages and display the splash screen. It can't even start if the library is not found. This is a problem for people who have headless Eclipse applications that run in places without such luxuries.

I raised a bug to track this issue. Though I should point out that bug is incorrect in its description of the launcher's linking: the launcher is dynamically linked to the graphics libraries, (not statically linked as the bug says). The problem is that these dependencies are resolved at loadtime, not runtime. The fix is to load the graphics libraries at runtime using dlopen and lookup all the functions we need to call using dlsym.

I have created launchers for GTK and Motif that do this and attached them in bugzilla. These changes require more testing before I release them to CVS. People should try them out and give feedback on the bug.


One thing to note is that the Motif version is using a DT_RPATH tag to help find the libXm.so.2 library that ships on linux in the root of Eclipse. Most of what I've read suggests this is obsolete and not a good idea, so that will probably change.

PDE Build Slides from EclipseCon 2007

The slides we (Sonia Dimitrov, Pascal Rapicault, and myself) presented at EclipseCon 2007 are now posted online. We're only about 6 months late putting them up.

They are attached to the Eclipsezilla entry for the tutorial. If you want to run the examples, you will need the Eclipse SDK and the RCP delta-pack. The examples were tested against an old integration build which is no longer available, but using 3.3 should work just fine.

Greasemonkey: Making the internet slightly less annoying

One of the more annoying memes I've seen on some blogs is the use of "Canadia" instead of "Canada". The level of annoyance has finally risen high enough to overcome a certain level of laziness on my part. So I downloaded Greasemonkey and wrote my first JavaScript.

I'm sure it is not the best script ever written, but I now feel like I've done my part to make the internet a better place.

// ==UserScript==
// @name          Canadia
// @description   Change "Canadia" to "Canada"
// @include       *
// ==/UserScript==

(function() {
var expression, replacement, regex, textnodes, node, s;

expression  = "([Cc]anad)ia([^n]|$)";
replacement = "$1a$2";

regex = new RegExp(expression, 'g');

textnodes = document.evaluate( "//body//text()", document, null,
             XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null);

for (var i = 0; i < textnodes.snapshotLength; i++) {
 node = textnodes.snapshotItem(i);
 s = node.data;
 s = s.replace(regex, replacement);
 node.data = s;
}
})();

Eclipse and the Console

Starting in the warmup to 3.3M7 there is a second launcher on Windows: eclipsec.exe.

The Eclipse launchers in 3.3 have had issues with various aspects of the console on Windows. See some bugs: 146807, 167310, 168726, and 173962.

All of our problems came from the fact that the eclipse.exe was linked as a UI application and not a console application. In 3.2, the console behaviour was tied to using java.exe instead of javaw.exe, but starting in 3.3 M5, the vm is loaded in the eclipse process using the JNI Invocation API.

So just like javaw/java, we now have eclipse/eclipsec. Eclipsec.exe is linked as a console application so that the OS handles allocating the console for us. Using eclipsec.exe does not imply any default arguments, so you still need to specify things like -console and -consoleLog.

Equinox launcher & Swing

The equinox launcher starts the Java VM using the JNI invocation API. Because we are such good friends with SWT (and also because it is easier) the VM was always started on the first thread. This turns out not to be so good when you want to run Swing on the Mac. There was a conversation about it over on EclipseZone.

So I fixed the bug (181698) today by adding a new option to the launcher "--launcher.secondThread". Use it if you want swing to work. This option can be compared to the -XstartOnFirstThread for the java launcher.

Source Feature generation with PDE/Build

One of the cool features in PDE/Build is the generation of source features and plug-ins. This is perhaps one of those features that leads towards the "black magic" reputation that we seem to have.

Recently the CDT SDK builds have been missing their source. The source features and plug-ins exist, but they just didn't contain any src.zips. After some investigation, it seems that a long standing bug in pde.build has risen to the surface. It has always been there, it was just hidden by bug 114150 which was fixed in M6.

The workaround for the CDT is simple: just make sure that in the SDK feature, the generated org.eclipse.cdt.source feature is included after the org.eclipse.cdt feature upon which it is based.

Unfortunately, I'm sure that the fix in pde.build will be a bit harder.

EclipseCon 2007

As everyone knows, EclipseCon 2007 is March 5-8. I will be presenting a long tutorial on PDE Build with Pascal Rapicault and Sonia Dimitrov. I will also be giving a short talk on the new launcher story.

I even got a pretty little graffic:

Feature Version Suffixes in PDE/Build

This week I released a patch from David Olsen which is a significant change to how pde/build calculates feature version suffixes. The details are in bug 157049, as well, the problems outlined in bug 162020 are fixed as a consequence.

The biggest thing to note is that the major, minor and service segments are now included in the calcuation. This covers the case when a plugin decrements its qualifier and increments, for example, the service number.

These changes will be in 3.3 M5. There may be cases where these changes could cause a one-time decrease in the version suffix, so builders picking up these changes are advised to increment their feature qualifiers.