In the last year I often had to held live presentations of Eclipse development. At that point a typical problem is, that the font sizes used during development are too small for the projector.
The possible solutions are either ignoring this fact, using a special environment, where all the appropriate settings have been made, or tweaking the development environment. The tweaking will not work, as several settings should be made, and they are easy to forget, while the special presentation environment seems too much of a hassle for me. This left as the only choice to ignore the fact.
But finally I had some hacking time, so I created a Presentation theme for Eclipse, that solves tweaking by a single selection of the user interface: Themes can be selected in the General/Appearance tab on the Preferences page.
Currently, the theme description is a bit hacky: for every platform the default font is copied by hand to the plugin.xml (using a Windows 7, a OpenSuse 11.3 Linux and a Snow Leopard machine). More research is needed to solve this in a more generic way. Luckily only four fonts have been redefined by the theme.
Some things missing: support for resizing elements in JFace viewers (such as EMF tree editors or CNF views), and the theme was not tested with graphical editors – although they can be resized using the Zoom control.
Finally, an early alpha version can be downloaded from our update site: http://eclipse.cubussapiens.hu
I’m looking for some feedback, or either alternative implementation ideas; I think, others have already met these problems.
After a month, some bugs from the Debug Visualisation version 0.8.0 have been fixed. Most notably, the incorrect trimming of long titles, and a case, where arcs were incorrectly removed from the graph.
Two minor new features were also introduced: it is possible to turn off name trimming, and the values of variables is now displayed as a hover.
I created a screencast to show these new features (and also some other, as the last screencast was created over a year ago.
(If the embedded video does not show in your feed reader, you can watch it on YouTube.)
Today I tried to edit an Ecore/Generator model used in the VIATRA2 framework, but the system greated me with an error screen stating, there are 4 errors in the selected Genmodel.
The error messages were a little bit cryptic (but all similar in nature): A containment reference of a type with a container feature platform:/resource/org.eclipse.viatra2.gtasm.model/model/gtasmmodel.ecore#//gtasm/metamodel/gt/GTPattern/namespace that requires instances to be contained elsewhere cannot be populated.
This was scary, as I don’t remember any new core features in EMF 2.6, that suggest such changes. My second guess was a misedited model, but after checking, that I have the same models as half year ago, this proved wrong. Even worse, these errors did not appear in either the Problems or Error log view. Checking the items mentioned in the error messages did not help, as the model elements looked “innocent enough” not to question their content.
It was only know when I saw that these errors are shown in a new, problem page in the editor (I often miss the editor pages option – except on form-based editors), and on the other page the tree is displayed, and code generation seemed also working.
At this point I looked on the internet for similar problems, and found a thread about the issue in the EMF newsgroup. The main idea was Ed Merks’s comment:
The point is supposed to be that you can’t be contained by more than one container, so you can’t have a container references that’s required as well as any other containment reference that’s not the opposite of that required container. I.e., a required container prevents other containment references from ever being populated.
Using this information I finally understood, what the error message meant, and begin looking for the cause in the Ecore model. After some searching (the error message only mentioned one model element from the three actors, and it is hard to get an overview of the inter modelelement relations in an EMF tree editor), I finally found the mentioned elements, that looked quite innocent at first – just take a look at the included graphical representation.
Illustration of the found problem
We have a machine, that contains both patterns and rules, while rules may contain addition pattern definitions (named local pattern definitions). On the other hand, patterns and rules have a backreference to the machine (namespace). As we wanted to have the Machine reference available for local patterns, the pattern references exactly one machine.
The drawback of the solution is, that the machine reference is the inverse of the containment relation, so every pattern has to be contained in a machine. On the other hand, EMF requires that every EObject (not EClass) must have exactly one incoming containment reference for serialization, so it is not possible for a rule to be the container of a pattern – hence the error message.
This analysis is extremely useful: it shows, that our metamodel prevents having serializable models in some cases, which comes in handy (I wouldn’t like to be the one, who has to debug such an error after a runtime exception is caught…). The fix is not really straightforward, as this model is already used (interesting fact, that the issue has not been produced in runtime – this means, we don’t have 100% test coverage :)), but by having a map to the error it is easier to fix.
I’d like to thank for the EMF team for this fine analysis solution, but some minor additions: don’t add warnings to a new page, use the existing reporting options; and try to rephrase the message for it to become more understandable.
Lately I have built several update sites during Eclipse development – e.g. for the last release of the Debug Visualisation plugin, or some related to VIATRA2 based articles (maybe more details later). They have all one thing in common: they were not created using Update site projects.
In my experience since P2 came as a provisining platform the Update site projects were not the best available solutions: at first (in Ganymede) they did not produce everything P2 needed, while produced legacy information, that triggered a backward compatible mode in the provisining platform (officially the old Update managers site.xml should not be used). Even worse, I experienced some serious errors, when trying to add a new version of the already added plug-ins to the already built update site – in most cases the category definitions were removed (as in Galileo by default all features without category are hidden, this problem is quite serious).
On the other hand, not too long ago classic update sites were also needed to provide update sites for both the Update manager and P2. Today the Update Manager compatibility is not as crucial, as all Eclipse versions supported by eclipse.org use P2, so it is better to use some dedicated P2-based mechanism for Update site creation.
This mechanism is present since Eclipse 3.4 (at least from the command line, as documented in the Eclipse wiki), but is a bit hard to use. Recently I found a somewhat hidden option in the GUI, that provides the P2 metadata generation functionality – just as needed.
To use this, at least one (or possibly more) features are needed – the features are the minimum installable units. When the features are ready and the related plug-ins are attached, the Export wizard has to be invoked with the Deployable Features wizard from the Plug-in Development category.
The deployable features and the destination should be selected as needed (in my experience the directory export makes possible the easiest update site deployment, while the zipped archive allows the easiest direct transport – e.g. for dropins).
Export deployable features wizard
The P2-related magic should be initiated on the Options page: if the Generate metadata repository option is selected, as in the screenshot, during the export all metadata needed by P2 is generated.
For categorization of the repository a specific xml-file should be created: by creating a Category Definition from the New… wizard a simple form-based editor can be used to define categories for the installer, that can also be selected using the Export wizard.
Some additional tips and tricks related to the deployment:
To update existing P2-based update sites, simply point the export destination to the already existing update site. This updates the existing update site – I only tried this using the directory-based output.
To avoid runtime issues, make sure that the exported plug-in projects use the needed Java version compatibility in the project settings (e.g. if the manifest requires Java 1.5, make sure the project gets compiled in Java 1.5 compatibility mode), as the plug-ins are recompiled using these settings. I managed to get a Java 1.5 compatible project compiled with Java 1.6 compliance settings – the plug-ins even got installed, but did not work in the target computer, instead a hard to debug runtime exception is thrown.
It is possible to add source boundles by selecting the appropriate checkbox. On the other hand I couldn’t find a way to set the display name of the generated source bundles, and they are shown with the same name as the non-source plug-in, making it hard to distinguish between them during runtime. If you know the solution, please let me know.
In general, this export mechanism works well, without any major issues, I tested in repeatedly with several update sites. Unless for some reason Update manager compatibility is needed, I don’t recommend using Update site projects anymore – simply export your features to deploy.
A month ago the Eclipse 3.6 shipped – again on time.
This is another evolutionary release – most components are binary compatible with the older ones, so the time of the migration was roughly equal to the download. All old favorites, such as Mylyn, EMF, etc. are updated, a lot of features were added, that makes development much easier. Some new components are also added, making a strong basis of the Eclipse eco-system.
The release features several improvements to the update mechanism, thus providing a whole new level of support for installing 3rd party plug-ins. These methods are based on the brand-new P2 provisioning API: the Modeling, Subversive or Mylyn Connector Discovery functions allows installing very specific plug-ins (making it easier to search for them), while the Eclipse Marketplace Client allows installing a wide selection of plug-ins (and this list keeps growing).
The Eclipse Marketplace Client in action
This solution is great, because I don’t have to remember/google for the various update site urls, and then manually select the features – if I don’t want to. If for whatever reason I need the specific knowledge, the “old” P2 user interface is still available.
A minor, but welcome addition is to the P2 interface the reliable cache clearing mechanism. It comes in handy when testing a new update site.
The Helios release is full of other gems, such as the graduated Xtext 1.0 with its new builder support, or the enhanced Variables and Breakpoints views in the Debug perspective.
My other favorite feature is the enhanced Cocoa-64 bit support for OSX – its performance/resource consumption is greatly improved, while the Dock icon overlays are also helpful (e.g. I can monitor the status a long-running task, while using another application).
Alltogether, the new release contains quite a few enhancements, that help the developers to provide better software using the framework, while maintaining the compatibility with older releases, thus making the switch easy (and possibly cheap) to do. I can hardly await the next (Indigo) release, and I’m looking forward to the new ideas of the e4 project.
