Tag: eclipse

Naming Maven repositories

Finding the root cause of a Maven build issue made me question my sanity, as seemingly everything I knew about Maven seemed to be wrong. Luckily, in the end logic was victorious, and quite a nasty bug was found.

Motto:

Caches are bugs waiting to happen. Rob Pike

The last two days I was hunting an issue in the Maven/Tycho based build of VIATRA: some artifacts from Maven Central were not found anymore, seemingly without any related change. A more detailed analysis has shown that the issue is specific to the build server at the Eclipse Foundation: in all other cases the builds run successfully.

When looking at the debug output of the build (the -X switch for mvn is truly a killer feature…) it was interesting that the build did not try to download the dependency from Maven Central nor from the mirror set up for builds at the Hudson instance at eclipse. Given that the first twenty-two modules compiled (with dependencies to Maven Central) this made no sense.

After managing the sanity loss and calling for help (thanks Ábel and Balázs) we have managed to identify that the settings.xml used on Hudson caused the problem. After calling for more help (thanks for the quick help from webmaster) I have finally managed to find out the root cause of the issue: repository identifier clash caused by the maven central mirror and a dependency issue.

For performance and network utilization reasons a mirror for maven central was set up about a month ago using the following fragment:

<mirrors>
    <mirror>
      <id>repo.eclipse.org</id>
      <name>Eclipse Central Proxy</name>
      <url>https://repo.eclipse.org/content/repositories/maven_central/</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
</mirrors>

Our problematic bundle had a repository declaration as follows:

<repositories>
    <repository>
        <id>repo.eclipse.org</id>
        <url>https://repo.eclipse.org/content/groups/releases/</url>
    </repository>
</repositories>

What happened here is that we declared some repositories with the same identifier as the proxy repository declared by webmaster, and Maven got confused, and thought that everything from Central is reachable from our declared dependency repository. Changing the identifier to avoid the name clash solved this issue nicely.

Now only one question remains: why was this issue not found earlier. The answer is trivial: the plugins were available in the local repository, effectively hiding the unresolvable dependencies. A completely unrelated cleanup of the local repository however has brought forth this issue, causing much headache to find.

The main lesson we learned here: DO NOT reuse the same repository identifier for multiple repositories. It can cause very subtle, hard to debug issues in the long run. However, there are a few other aspects you have to keep in mind:

  • All repositories and plugin repositories defined in your parent project are also inherited, so their name should also be unique.
  • Identifier clash might not be a problem in case of deployment repositories, but have not tested this aspect yet.
  • A more specific lesson for Eclipse projects building on Foundation Servers: DO NOT use the identifier “repo.eclipse.org” for your repositories. Maybe it is worth checking whether the identifier is used (e.g. use following the github search link to check projects developed or mirrored to the Eclipse Github organization), and update accordingly. Update: the mirror repository id was updated to “eclipse.maven.central.mirror” that should not clash with manual repository names.

Xtext Reflective Editor updated for Kepler

Today a new Eclipse version codenamed Kepler was released, with a lot of nice new features, including conflict handling during update, an update user interface for the Marketplace client or various EGit updates (my favorite is the Commit and Push button in the Commit dialog).

About the less visible stuff, in the modeling projects we use, e.g. EMF, Graphiti or Xtext also got some internal updates, resulting in the need to update our projects. As of now, I updated the Xtext Reflective Editor, as a change in EMF 2.9 made it unusable in Kepler.

I often use this tool to debug the Xtext-based parsers that use Xbase and model inferrers, as it displays the generated model using the EMF reflective editors. Version 0.5.5 is a recommended minor update – it works on both newer EMF/Xtext versions, but maintains compatibility with older EMF versions. It is still downloadable from our update site http://eclipse.cubussapiens.hu.

Thanks for all contributors the new, nice features of Kepler (and of course fixes as well). This can become a new platform for new projects for me – the reflective editor update is only the first of them.

Hi-DPI Eclipse screenshots

Motto:

A picture is worth a thousand words.

Recently I was writing a paper based on EMF-IncQuery, and I wanted to include some screenshots. For good reasons, a 300 dpi photo was recommended, but that represents quite large resolutions for reasonably sized images. Although I couldn’t always get this resolution, but I found some nice tricks to use for later.

Eclipse always allowed configuring some fonts – some time ago I experimented with the theming capabilities of Eclipse 3.x, and could increase a few font sizes, but some widgets such as list or tree viewers did not support such theming. ((Note to myself: I want to experiment with the 4.x theming capabilities, and update the presentation theme to work with the CSS-based themes of e4.))

GMF-based editors, such as the Papyrus UML editor or the Ecore Diagram editor provide support for exporting the diagram in PDF format – a format that retains (most ((However, I did see some interesting glitches related to the background settings of Ecore Diagrams…))) graphical information of the diagram in a vector-graphic format, usable for inclusion in LaTeX documents.

The multitouch zooming support for Zest graphs also helped a lot for screenshots, as I could simply use all available screen area to get a nice shot. Even for graphs that do not contribute their Zoom Managers to the user interface.

Finally, OSX already supports Hi-DPI modes for its entire operating system (dubbed Retina Display), that can also be enabled on non-Retina displays with some hacking: basically by downloading the Quartz Debug program (details for Lion and Mountain Lion) I can reduce the visible resolution to 960×540 pixel on my Full HD monitor. It also supports the use of one monitor as HiDPI and the other as normal – that comes quite hand with applications that do not support HiDPI mode (such as Eclipse out of the box, or Firefox).

OSX supports HiDPI modes

One big issue was that Eclipse 4.2 does not support HiDPI resolutions out of the box. Luckily, this was already evaluated in Bugzilla, and in a corresponding Stack Exchange entry.  Basically, the info.plist file ((By the way, the XML syntax of the plist files is something awful – it reminds me of the parameter handling in shell scripts or console applications – odd numbered parameters are the keys while even ones are the values. Not that XML allows the definition of attributes or inlined elements – but who cares?)) of the Eclipse.app has to be updated to state it supports High DPI mode, and then the Application itself moved in order to OSX detect the changes.

As a result: Eclipse sees that it has a limited amount screen estate, while in practice it uses 4 times as many pixels. While it is not usable at all for everyday programming, it helped a lot for screenshot creation. ((Except when using Skitch – a nice screenshot manager app. But it does not know about the underlying HiDPI mode, and always created a low DPI shot.))

A low DPI version of a small screenshot
A HiDPI version of the same editor

Alltogether, there are various ways to create high definition screenshots in Eclipse. It helps knowing them and using accordingly. For this reason, I am curious what other ways are there to create screenshots with high resolution – how do you do it?

EMF-IncQuery: First public release

One of the most common tasks when working with models is executing queries on them (e.g. finding a set of corresponding model elements for code generation or finding violations for model constraints) – quite often repeatedly. To allow effective calculation and recalculation, an index of the EMF model has to be created and maintained during editing operations.

EMF-IncQuery is a tool we are developing at the Budapest University of Technology and Economics try to solve this issue by providing a runtime library for these indexes, and additionally an Eclipse-based tooling to specify and debug such queries. I have already blogged about a validation framework based on this technology, and my collegue, István Ráth gave a short presentation in last year’s EclipseCon Europe Modeling Symposium.

However, previous tool demos were held using a tooling and query language originally created for the VIATRA2 model transformation framework, so it was somewhat hard to use. Since these demonstrations we created a new, Xtext-based tooling using a modified query language that fits the EMF model specifications better.

The Xtext-based editor with type information hovers.

Another new user interface component is the Query Explorer: a view that allows evaluating developed queries without using the generated code in a new Eclipse instance, while allowing the reuse of existing domain editors.

The Query Explorer can be used to evaluate patterns using existing model editors.

As for examples, since last year we developed two new case studies for EMF-IncQuery:

  1. Derived features allow the creation of EMF derived features based on incremental queries as backend;
  2. We also created connectors for JFace databinding for query results allowing query-backed automatically updating user interfaces.

Even better, this new version is available since Wednesday – for a detailed release notes see the announcement post in our homepage. If you want to download this release, you can use the Eclipse Marketplace client (at least if search is working as expected – today we managed to not find our software there using the built-in search 🙁 ). Alternatively, EMF-IncQuery is available from our update site: http://viatra.inf.mit.bme.hu/update/incquery/

Alltogether, the new EMF-IncQuery release marks an important point: we believe at this point, it is ready for use. For me, this is an important checkpoint, as in the last year I put a considerable effort of getting this rolling.

As for the future, EMF-IncQuery is on its track to becoming an Eclipse project: the creation review is scheduled for the 10th October 2012. After the creation, we plan to migrate our codebase, and have of course further ideas on how to improve the system to be usable in more and more cases.

Lesson of the day: Beware the indirect dependencies in Eclipse 4.2

Executive summary: If you cannot move or minimize your views in Eclipse 4.2, always check whether the org.eclipse.e4.ui.workbench.addons.swt bundle is present in your run configuration.

A view misses its minimize icon

Today Eclipse surprised me with a nice feature. I tried to reconfigure my runtime workbench to create some screenshots, but I couldn’t. The views were missing the minimize button, and dragging view parts between groups did not work.

I had some minor issues with the new workbench model, so first I tried to check everything is at its base setting. I reset the perspective, closed all perspectives, restarted the workbench, but nothing helped. Finally, I noticed a short error message in the Error log:

Unable to retrieve the bundle from the URI:
bundleclass://org.eclipse.e4.ui.workbench.addons.swt/org.eclipse.e4.ui.workbench.addons.minmax.MinMaxAddon

That provided the required hint: to conserve memory, I usually start a runtime Eclipse with a reduced set of plug-ins – possibly a dependency is missing. Looking at the uri from the error message, I found, that the org.eclipse.e4.ui.workbench.addons.swt plug-in was not added to the Run configuration. I checked the corresponding box, and voilá – everything worked as expected.

What makes this case more interesting is that the built-in dependency validation report no issues. I had my own debugging sessions because of missing dependencies, so I set all my Run configurations to validate every dependency at startup. This means, this plug-in is not needed for executing the platform (technically true), however, when it is missing, it strongly reduces the usability.

Alltogether, what I am missing is some kind of higher-level validation that could report such issues. But in the meantime, I publish this, hoping, someone else finds it useful.