EMF Ecore model inheritance

Let's say you have a common.ecore with Node element. You create person.ecore in another plugin and want Person->Node inheritance. To do this create your person.ecore and load common.ecore from "Sample Ecore Editor" menu. Continue creating Person element and setting super type as node. Now, when it's time generate genmodel for person.ecore on package selection page of wizard you will see packages for person and common. Make sure you don't select common checkbox and instead choose common.ecore from "Reference generator models" pane. If you don't then person model will expect common to be on the same level as itself and you don't want that.

setting build.id in about.mappings

http://www.eclipse.org/forums/index.php/t/216978/

https://bugs.eclipse.org/bugs/show_bug.cgi?id=309144

Pass -Dbuild.id= when you perform your site.p2 action

The Buckminster property expansion falls back to Eclipse variable
expansion so this should work:

build_id = ${env_var:BUILD_ID}

That timestamp will differ between projects. It finds the last
modification in the subtree and uses that so it's not suitable to use as
a build_id.

Find ImageDescriptor

public static ImageDescriptor findImageDescriptor(String path) {
  final IPath p = new Path(path);
  if (p.isAbsolute() && p.segmentCount() > 1) {
   return AbstractUIPlugin.imageDescriptorFromPlugin(p.segment(0), p
     .removeFirstSegments(1).makeAbsolute().toString());
  } else {
   return getBundledImageDescriptor(p.makeAbsolute().toString());
  }
 }

Change default messages when using EMF Validation Framework

The easiest way to do it if feature names are no issue is to create fragment with host o.e.emf.ecore and define plugin_en.properties file with values for message keys changed to your needs.

plugin.properties fails to replace referenced key string

If this happens make sure Bundle-Localization: plugin is in Manifest.mf

The simplest possible Buckminster example

While at EclipseCon 2011 Miles Parker and I decided to conduct our own Buckminster BoF. Yes, this year's conference was all about Maven/Tycho builds, but we though that Buckminster had its own advantages that people might find beneficial to them.

For the BoF I created a very simple Buckminster build that build a very simple RCP application, in fact the RCP is so simple that it's just a window. The point of this is just to show a bare bone Buckminster build and give user instant gratification in actually building something quick. In fact, this bare bone build can be used for more complicated project because the beauty of Buckminster is that it does not need any more information that you already have - features and plugins.

If you are just starting out with Buckminster checkout Ralf Ebert's article as a starting point, get familiar with Bucky Book and of course visit Buckminster forum as it has vast amount of information that other people and myself were faced while working with Buckminster.

Grab Buckminster example here

Also, here are notes about Buckminster that were generated while implementing it for our build, hopefully these will be useful to someone.

Power of Buckminster's advisor nodes

Yesterday while working on updating GMF plugins with new model I had some changes in my workspace that produced compilation errors. I did not have time to fix the errors by the end of the day but with the changes I had, I did not want to leave them in my workspace without checking them into SVN. You know what they say "If it's not in version control, it does not exist." However, checking in these changes into SVN would mean that the build would break. Yes, I could have re-branches the changes, but did not have time for that either. What's the solution? Buckminster's advisor nodes! Here is what I did in my cquery:

I added three advisor nodes that set revision to last good revision of the plugins. That's it. During materialization three plugins with revision 63870 will be checked out and although latest revision has compilation errors, build will still work.