Alex headshot

AlBlue’s Blog

Macs, Modularity and More

Adventures in Multi-Architecture Eclipse

Rant 2011 Eclipse

To bring to an end the sorry saga of trying to make a multi-architecture Eclipse build, the conclusion appears to be that it is impossible due to limitations in P2.

Although in my last post, I claimed to have success in having a per-architecture “configuration” directory and “eclipse.ini” file, the reality is that P2 leaps to the rescue in breaking what otherwise would be a fine set up. And I don't care how it's supposed to be capitalised.

The problem is twofold:

  1. An Eclipse P2 profile, written into the location is single-architecture by design
  2. P2 doesn't check what the location of the configuration dir or eclipse.ini files are during updates; it just assumes they have the standard values

Earlier attempts of generating two profiles (on a per-architecture basis) succeeded in getting the application off the ground. However, since P2 also writes into configuration/org.eclipse.equinox.simpleconfigurator/, we have to split the configuration directories as well.

Conventionally, the configuration directory is called configuration, but you can change it with a command-line switch (-configuration) or with an entry in the eclipse.ini file. This value is known at runtime (go to the 'About' page and you see it shown at the top) but P2 thinks it's still called configuration, regardless of what it actually is.

Not only that, but the eclipse.ini isn't always called eclipse.ini. The actual lookup is product.ini, with a fallback to eclipse.ini, if the product-specific one can't be found. This allows you to rename the launcher to something else, or (originally) to have multiple products in a single location.

Sadly, whilst you can launch a multi-architecture build using the previous case, you can't update it. P2 will write entries out to eclipse.ini and configuration, which if you've called them eclipse32.ini and configuration32 are of no use. Ironically, the plugins do actually get loaded and installed into the plugins directory; it's just the P2 metadata which is written to the wrong place. In The Good Old Days, you'd have been able to run eclipse -clean and it would have just worked – though to be honest, a multi-architecture would have just worked then as well.

All of this brings us to the conclusion that a single package, multi-architecture build is not going to happen with products in one folder. It might be possible to have one folder per executable with a shared plugin or feature store; but by the time you get to that, why not just stick all the plugins and features into a local M2_REPO type cache and just run from there?

Notes: yes, there's a bug, so please don't leave a comment asking whether I've raised one. And in all honesty, if you're going to leave a comment with P2 vs p2, then I'd much prefer you spent less time worrying about what people are calling your product and more time on getting it to work.