Imediava's Blog

Just another site

Monthly Archives: April 2011

Sonar: Hide snapshot from the TimeMachine

If you use Sonar ( as your code quality control tool maybe at some point you’ve wondered how you can delete a snapshots which no longer provide useful data.

You can run into this problem if you run a sonar measurement over a failed build or if you change the quality profile of your server for testing purposes and you wanna get rid of that confusing data later.

The problem is that those snapshots are not useful for you anymore yet there’s no way to hide them. This affects specially the TimeMachine section where the graph is altered by those useless snapshots.

As far as I know Sonar doesn’t provide a way to do this through it’s interface. The only alternative I’ve found it’s extracted from the following Jira issue:

To make use of this tip you need to have access to the database that stores Sonar data. Once you’re logged into the database server you can identify the ids of the snapshots you wanna hide with the following SQL query that list all the snapshots of a project:

select as snapshot_id,, p.kee,  s.created_at 
         from projects p, snapshots s 
         where s.project_id = and p.scope = 'PRJ' and p.qualifier='TRK' and name like "%MyProjectName%" 
         order by s.created_at desc

Now that we have the id of the snapshot we wanna hide we can make it invisible with the following update statement:

update snapshots 
         set status='U' 
         where root_snapshot_id='${snapshot_id}' or id ='${snapshot_id}'

Hide a project from the workspace in Eclipse

When you’re developing an Eclipse plugin sometimes you need to use the functionality JDT provides for tasks you don’t want the users of your plugin to be aware of. I ran into an example of this while developing a plugin. I needed to create a project in the workspace that I didn’t want users to see.

The solution came from the JavaElementFilters extension. To set up this extension you have to go to your plugin.xml file and add something like the following:

          description="Description of the filter you wanna create."

The description of each of this fields can be found at:

However the most important field is the class field. The class field points out to the actual class which implements the project filter. This class must extend org.eclipse.jface.viewers.ViewerFilter. To extend this abstract class we just have to override the select method. As an example of overriding this method I’m gonna use the code I used to solve my initial problem:

	public boolean select(Viewer viewer, Object parentElement, Object element) {
		if(element instanceof IJavaProject){
			return !((IJavaProject) element).getElementName().equals("ProjectNameToFilter");
		return true;

What this example does is just:

  • First it makes sure that the element received is an instance of IJavaProject (it’s a Java project in the workspace).
  • Then it filters the project if it has a concrete name.

PS: I have to thank Prakash from for redirecting me to the JavaElementFilters extension as the solution of my problem.

Prototyping SWT with GroovyMonkey

As a part of an Eclipse plugin I’m developing for my Master’s degree project lately I’ve had to deal with SWT.  Coming from some background at developing GUIs with Swing and Windows Forms I have to admit that SWT it’s not easy to learn. Apart from a bit counterintuitive I find it too verbose.

So far, whenever I wanted to develop a new Wizard or View I had to code it and play with layouts and widgets till I got the look I wanted.

On the other hand, just quite recently I’ve discovered that there’s an scripting environment for Eclipse called GroovyMonkey that can help the task of protoyping with SWT.

To play with it, I’m gonna use an example to compare the code you need to write to create a really simple interface with both approaches to show GroovyMonkey benefits over Java SWT. The example I’m gonna use is extracted from the installation of GroovyMonkey in Eclipse. We’re gonna create the following shell:

Example Shell

The code for this shell with SWT and Java is quite long for what it does, not too elegant and prone to error.

public void createPartControl(final Composite parent) {

     parent.setLayout(new GridLayout());
     group = new Group(parent, SWT.NONE);
     group.setText("Groovy SWT");
     group.setLayout(new GridLayout());

     Label label1 = new Label(group, SWT.NONE);
     label1.setText("groove fun !" );

     Label label2 = new Label(group, SWT.NONE);


The code we would need with GroovyMonkey is shorter and simpler to understand. Advantages whose impact grows with more complex user interfaces.

 def subapp = window.getShell())
    group( text:"Groovy SWT", background:[255, 255, 255] )
        label( text:"groove fun !" ,background:[255, 255, 255] )
        label( text:"Email:", background:[255, 255, 255] )

So, those features have made me decide to give GrooveMonkey a try as my tool for quick GUI prototyping with SWT. In the following section, I’m gonna share my experience through a small list of tips I myself find useful.

Since I’m a completely beginner with GrooveMonkey and with Groovy in general, some of the tips may seem extremely obvious for somewhat experienced users. Nonetheless It haven’t been easy for me to find information about how to start with GroovyMonkey. Thus, this article is written with the hope that it can somehow be useful to those like me who have never used GroovyMonkey before and need help in their very first steps.


Check GroovySWT documentation

This applies to you specially if you’re using GroovyMonkey for prototyping SWT GUIs like I’m doing.
GroovySWT webpage provides a short explanation of the way the library works. If you wanna dig deeper the examples it provides should become your best source.

How to assign values to fields

To assign a value to a field you can take to approaches: either you use the classical “set” method provided by the Java API or you pass the value as a named parameter to the object constructor.

The first way is more flexible since it allows to change the value of the object at any point of the execution. The code to use this approach for setting the text of a label example shell is similar to the Java code:

   miLabel.setText("groove fun !")

On the other hand, the second way is more concise and it’s the preferable way to assign values when creating objects.

   text(text : "groove fun !")

It’s important to point out that this way of assigning values to properties can be used for any property which follows the naming convention marked for JavaBeans. As an illustration we are gonna use the same approach to assign layout data to a control. This can be done since the method setLayoutData exists for any control. The following snippet shows how to do it.

import org.eclipse.swt.layout.GridData

text(style: "Border", layoutData: gridData(grabExcessHorizontalSpace : true, horizontalAlignment : GridData.FILL, verticalAlignment : GridData.FILL))

The last example also shows that this approach can be used recursively, this way increasing it’s benefits.

Styles for controls

The way styles are asigned to controls is also changed with GroovyMonkey.

GroovyMonkey takes the SWT.None as a default value that doesn’t need to be expressed to be assigned to a control.

When other style values need to be assigned the way to do it is passing them through the named parameter style. The value for this parameter is a string which contains the list of styles we wanna set, separated with commas. To represent every style we need to use it’s name deprived from the SWT prefix. Uppercases are ignored so any representation with the same letters as the style name is accepted by GroovyMonkey.

As an example this is the way to create a mulitilined text field with border:

text ( style: 'Border, Multi')

So that’s all for now. Maybe I’ll come back with more tips for GroovyMonkey users when I have more experience with it.

%d bloggers like this: