Headless Build Benefits

Several weeks ago I blogged a lot about headless build and mainly about the problems I encountered to set up this build. I must admit that it was difficult and long to have the final build working properly but I also MUST admit than the benefits are now really appreciable.

These benefits are mainly :

1. Each time we have to release our features I feel confident. First, I am confident about the content of the packages thanks to automation. Then I am also confident about the compiled code build in the packages thanks to the integration of our J-Unit tests in the build.
2. The workload to perform the release thanks to the headless build can be summed-up by: ./manu-linux-build.sh build.all. In other words, it’s FREE. Who wants a release ?? You or you ? You ? No problem I can do that in one click !! You need an engineering release ? Ok here it is !!!

If your are not already building your Eclipse’s product automatically I strongly encourage you to get started with headless build.

Manu

Eclipse Jobs And JDBC

Today I refactored one long action of our product in order to use jobs.

In one of our custom views the end user can click on an “Open Statistics Views” action. This action asks to a Statistics module to compute some stats. These statistics are computed from a local database and the computation can take several seconds (up to ~30s). Before today all the action was performed directly in the UI thread. I am already earing most of you saying: “What ??!!! You are freezing the UI for 30 seconds ??? Yes I am (shame on me), and yes I know it’s bad and that’s why I decided to change that.

The first thing I looked to fix this issue was Eclipse’s Jobs. The API is straightforward and quite easy to learn. Quickly I had my call to statistic module performing stats computation running in a Job using an IProgressMonitor of type UNKNOWN.
Here is the code

StatJob statJob = new StatJob("Computing Statistics");
		statJob.setUser(false);
		statJob.addJobChangeListener(new JobChangeAdapter() {
			public void done(final IJobChangeEvent event) {
				if (event.getResult().isOK()) {
                    // UI update using job run method result
					PlatformUI.getWorkbench().getDisplay().syncExec(
							new Runnable() {
								public void run() {
									StatJob statJob = (StatJob) event.getJob();
									setInput(statJob.sessionStat);
								}
							});
				}
			}
		});
		statJob.schedule();

Notice the use of an IJobChangeListener in order to update the view when the Job’s work will be done.

This solution is better than performing stats computation in the UI thread but there is still an “issue”: what about progress feedback to the user ??. The UNKNOWN type only says to the user: “Something is happening, I am working but I can’t tell you when I’ll finish”

Since the stats are performed using mainly 2 SQL requests through JDBC I can only divide my Job in 2 amount of work . Moreover one of this two SQL request is longer than the other so dividing 30 seconds of work into 2 seconds and 28 seconds will not help the user.

After browsing the JDBC Api and mainly the Statement’s one “I discovered” the cancel() method documented as following: “Cancels this Statement object if both the DBMS and driver support aborting an SQL statement. This method can be used by one thread to cancel a statement that is being executed by another thread.“

First attempts using this methods didn’t succeeded and resulted in SQLException. I’ll investigate more on the subject (for info we are using an SQLite database with Zentus JDBC driver) but I would be interested about the way you provide progress feedback  to the user when accessing database ?

Manu

Eclipse Keyboard Shortcuts

Several times ago one of our user asked for us to add keyboard shortcuts for our plugins actions. Our answer was: Easy !!!

Quickly, using Eclipse command “framework” (bindings extension point) this  feature was implemented.

Now ……………………………. the problems we encountered since there

1. Due to our plugins name our keyboard shortcuts appeared at the top position in the in the “help” providing list of available plug-ins. This can be a “problem” for users which doesn’t use a lot our plug-ins
2. More tricky, some of our shortcuts were hiding Eclipse’s default shortcuts !!!!!

After quick investigations it seems only really important actions are binded by default with keyboard. Other actions CAN be binded by the user later through the Eclipse preferences pages. We should decide if we change our shortcuts in order to not interfer with others or to simply remove them …

I would be interested to know the way you manage your keyboard shortcuts,and to have any links pointing to that topic (I didn’t find anything after quick googling) ??

I know that there is an associated “rule” in the “Building Quality Plug-ins” book but I don’t have the book here at home and I can’t rember the exact rule saying: “your plug-ins should only provide “additional / optional” features “

Manu