Advanced eclipse and Rational Team Concert (RTC) tips

I spend pretty much most days working in and around RTC, an Eclipse-based tool for development and agile project development. Many of the great features are very obvious, others are not so much, but still really very helpful. Here I thought I would pull together some of the less obvious features of RTC and eclipse that are none the less very powerful and helpful, if only for the lazy (like me)

RTC – First the set which are specific to RTC.

Rational Team Concert provides a very flexible tool for managing agile development from planning to coding through to building and managing several releases. Among the less obvious options are:

ctrl+alt+w – This brings up a search dialog which lets you search for defects/tasks by number of just words that appear in the title or description. Yes the box in the bottom right hand of the window does the same thing. But some people don’t like to reach for the mouse, if a few key presses will do.

Team:History – If you right click on any file which is from a connected RTC respository you get a Team menu with some useful options in it. History will simply show you every changeset that has applied to this file, and give you indications of where concurrent development happened causing merges to be necessary.

Team:Annotate – Even better than just the flat history is annotate, this marks up the whole file by line to show you exactly when the last change to that line occurred. This is super handy to answer that key question ‘ Who on earth did *that*?’

Extract workitem – When working with Stories, Tasks or defects you often build up a hierarchical model of work that needs to be done, you start with a story explaining that you will deliver x,y &z, then create tasks to deliver x, y &z. If you select text in the description of a story (or task/defect etc) you get an option ‘Extract workitem’ this takes the selected text and creates you a new work item with that description, which is linked to this parent item. Can be very handy when getting your initial work break down sorted out.

Component history – For a complicated project split across several teams in different locations, getting an overview of what is actually going on in any given area of the code can be difficult, However RTC provides the ability to see the history of all changes going in against a given component in a stream. Go to Team Artifacts->Project->Source Control->-> right click and go to show->History. This then shows you every change set delivered against this component in time order. Assuming comments are helpful then you get a pretty good view of what is going on and how frantic the pace of delivery is.

Find change sets by this author – To further drill in to what is being done, and by whom, you can right click on any of these history items and look for ‘changes sets by this author’ Which allows you to construct a query to find every change delivered by someone in particular, either against a specific component, or across the whole project.

Work item history – RTC manages changes to source, but also stores changes to it’s own artifacts. Sometimes it is very useful to check what the life of a work item has been, the last tab on a work item is often ignored, but it shows a time line of events on this work item, and a list of every change that has occurred since it was originally opened.

Eclipse general awesomeness

RTC is built on top of eclipse which provides quite a lot of great features on it’s own. One great feature, which I won’t go into here, is the ability to write your own extensions, such as custom editors. I once wrote my own editor for a proprietary test language, to provide some of the nice features I’m used to from Java, such as content formatting and basic error detection.

Here are a few options that many people just don’t realise exist:

Java Templates: – If you don’t know what these are, open up a Java program in eclipse type ‘sysout’ then hit ctrl-space. What you will find is that it is expanded out to the Java ‘System.out.println();’ with your cursor left between the brackets ready to enter parameters. The great thing about templates is that you can add your own. Go to Window->Preferences and navigate to Java->Editor->Templates This view shows many templates for all kinds of file types. Having a quick play with this it soon easy to create your own rules. For instance a simple one to auto-insert entry and exit trace for a Java method looks like this:

Context is Java, the Name is ‘iftrace’ (eg if trace is enabled do trace) The rule is as follows:

if (TraceComponent.isAnyTracingEnabled() && tc.isEntryEnabled()) Tr.entry(this, tc, “${enclosing_method}”, ${enclosing_method_arguments});


if (TraceComponent.isAnyTracingEnabled() && tc.isEntryEnabled()) Tr.exit(tc, “${enclosing_method}”);

This is a fairly standard layout, if some tracing flags are set, then Trace entry and exit, the cool bit is the ${enclosing_method} which will get pre-filled with the name of this method, ${enclosing_method_arguments} which expand to the values called with,  and the ${cursor} which lets me chose where to leave the cursor when the insert is done. This means I can write my method definition, then do a quick iftrace and presto I have a method with entry/exit trace in place.

/**<enter> auto fill in parameter names – On a similar note once you’ve written your method signature, you can add some Java doc comments, by doing this *after* you’ve written the method signature, when you write /**<enter> above the method, it magically pre-fills the parameter info in the Java doc comment, ready for you to fill out the information. It’s not much, but it saves a few key presses.

Typing – Automatically close/insert options – Again under window->preferences and the Java->Editor section there are a bunch of options for whether you’d like eclipse to magically close things like strings and parentheses for you. I personally like to switch all these on, less typing for me, but if it bugs you, it’s nice to know you can switch them all off too.

Source/refactor -> If you right click in a Java program there are two great menus, Source and Refactor. These contain loads of really helpful options to save you time. For instance you can declare a bunch of variables in your class, then just select them and right click->source->generate getters/setters and it will quickly allow you to create basic getter/setters for all the selected variables. There are loads of options here, it’s well worth playing to see how much time they can save you

Yellow lightbulbs/Red X’s – > Okay so this one most people really should have noticed, but just in case, just so I can sleep easy knowing that no one has missed it, when there is stuff wrong with your code, most of the time eclipse will put a little yellow light bulb against the line, or even a red X, if you click on this it will often contain a list of suggested fixes. For some things there are no really useful fixes. But for a surprising number you can just double click on the suggestion and eclipse will go fix it for you!

block indent/unindent-> when fixing indenting, particularly in something like Python, it’s not necessarily immediately obvious that you can select several lines and hit tab and rather than replace the contents with a tab (as with a normal text editor) it will just indent all the selected lines. And shift+tab will unindent the lines.

ctrl-o – brings up the outline view as a hover over pop up. This can mean you don’t need the outline view up all the time taking up screen space, but can quickly refer to it as necessary.

So that’s it for the moment, some may be pretty obvious, but hopefully there is at least something in the list that you didn’t know and which can now save you some time. If you have any other unobvious tips please share them!