Debug of Eclipse UI elements with Aspects

I tried to fix issue with Octave code autocompletion in Octclipse and ran into a difficult situation when I wasn't able to understand what is going on in internals.

Usually it is possible to use debugger for such purposes, but I was dealing with UI and this added me troubles - autocompletion popup is hidden on focus lost and it is not possible to use breakpoints. So, I decided to use trace technique, but I wanted to debug not my own code, but DLTK.

So, the only solution I knew for such a problem is Aspect Oriented Programming (AOP). It is well-known, how to use AspectJ for standalone application, there are also a lot of information on AOP in spring. But to introduce AOP in Eclipse plugins (which are OSGi based) those solutions are not applicable.

In general, there is a way to use Spring AOP in OSGi with Spring DM, but it is very heavy and I didn't want to setup that monster just to trace few method calls.

Fortunately, Eclipse Equinox has more lightweight solution for AOP, called Equinox Aspects. The quick start guide can be found at http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-quick-start.php .

I've gone through this manual, tested first aspects on the Octclipse project and then wrote a simple aspect like


before() : cflowbelow(execution(void net.sf.octclipse.internal.codeassist.OctaveCompletionEngine.complete(..))) &&
execution(* *.*(..)) && !within(TraceAspect){

try {
System.out.println(thisJoinPoint);
} catch (Exception e) {
}
}


Then, it is necessary to filter too low-level methods execution (for each specific case), and implement more comprehensive logic. 


One more note, is that it is better to not use Require-Bundle for specifying plugins to weave, but Eclipse-SuplementBundle. In other case it is easy to run into an exception "error can't determine modifiersofmissing type". Sometimes it can be fixed with adding ";visibility:=reexport" to the bundle name in Require-Bundle directive, but someties - not.

Migrating to Maven 3 and Eclipse Tycho

First refactoring I decided to introduce was the automation of the build process using Apache Maven.

The reason is overhead of using Eclipse PDE every time to build an application. With it we must do export every time to build distribution packages. Also, it is not easy to do builds for multiple platforms using Eclipse PDE.

And the solution is Maven 3 and a set of plugins called Eclipse Tycho. These tools allow to build eclipse plugins and applications in head-less mode simply in command line.

Tycho brings a lot of useful features with it:

• headless build
• JUnit integration tests support
• dependency management (a bit unhandy)
• continious integration support
• reports generation and other maven features

So, we migrated to Tycho-driven build process. Migration was succesful, but list of modules (previously Eclipse projects) changed, due to attempts to introduce JUnit testing modules.

Later I will write a bit more about Tycho-related issues.

Initial state of the project

First, I want to describe current situation with Octclipse project. To be honest, this project is a really good job! There are a lot of features and I still don't understand everything.

Octclipse is based on Eclipse DLTK (Dynamic Language ToolKit) project. It already has two source parsers, syntax highlighting, launching support, initial debug support, integrated Octave help and many other features.

What is wrong now?

1. Parsers.
One parser is Java-based, implemented with BYACC/J and JFlex. That means, its' grammar was implemented manually and that's why was not complete. Octclipse grammar file size is 3 times smaller than original Octave grammar. So, there are a lot of small issues with parsing (but in general it works on simple sources)

Example of parsing issue:
if  (2 > 1),
  x = 1:10;
  x(end-2:end)
end;

This code is correct and can be executed in Octave without any problems.

The problem relates to 'end' keyword. This special case of using 'end' in vectors to point to the last element was just forgotten (or it was difficult to implement this case).

Second parser is a native one. The main idea is to use native octave parser to determine tokens semantic. That is reasonable, because if something works in Octave, it should work in Octclipse. The problem is that now this parser doesn't work at all due to some changes in AST (Abstract Syntax Tree) classes. Beside, its' architecture is very sophisticated now:

• User must compile and install native library himself
• Native library parses source file and converts it to XML
• In Java-side, ANTXR-based parser converts XML to AST

2. Debug
I didn't manage to run debug yet, because it also requires compiling a native library.

There are also two more native libraries, but I didn't understand their goal yet.

Octclipse reincarnation

Once I decided to start working with Octave and looked for available graphical user interfaces for it.

Sadly, all projects I've found are dead. Even the most usable one - QtOctave was finished in June 2011. So, I decided to make my contribution to Open-Source World and to pick up some of those projects.

I already had some expirience with Eclipse plugins development, so my choice was to contribute Octclipse project. Besides, I think, Eclipse is the most powerful platform for building IDEs.

I wrote an email to Ryan Rusaw, author of this project and he gave me administrative rights for project on sourceforge and permissions to do everything what I want to improve the project.

Ok, I will try to do all my best. My first goal to make it runnable without any native code compilation (as it is now) and make it usable at least as QtOctave is.

And I will write here about state-of-art, some important changes, design solutions and so forth.