Wonderful though Clearcase is, its support tools leave a lot to be desired. Take the file comparison application that comes bundled. It only flags lines which have changed, so you often have to spend a couple of moments scanning the line to spot the changes. There are loads of file comparers out there to choose from. So here is how to integrate it with Clearcase.

The simplest way is to find a file comparer with Clearcase integration capabilities like KDiff3. The integration is simple:

1. Download KDiff3 and install.
2. Run it up.
3. From the menu select Settings->Configure KDiff3.
4. Go into the Operation tab.
5. Click Integrate with Clearcase.
6. Click Ok.

Simple, but what if your file comparison tool doesn’t have an integrate with Clearcase button? Changing the Clearcase hooks is quite straight forward. The mapping file exists in:

<installation-root>\ClearCase\lib\mgrs\map

The file is keyed in extension (or class) and action, so replace the following lines in the map file.

_rftdef            xcompare  C:\Program Files\KDiff3\kdiff3.exe
_rftmap            xcompare  C:\Program Files\KDiff3\kdiff3.exe
_rftvp             xcompare  C:\Program Files\KDiff3\kdiff3.exe
_xml               xcompare  C:\Program Files\KDiff3\kdiff3.exe
_xml               xmerge    C:\Program Files\KDiff3\kdiff3.exe
_xml2              xcompare  C:\Program Files\KDiff3\kdiff3.exe
_xml2              xmerge    C:\Program Files\KDiff3\kdiff3.exe
_xtools            xcompare  C:\Program Files\KDiff3\kdiff3.exe
text_file_delta    xcompare  C:\Program Files\KDiff3\kdiff3.exe
text_file_delta    xmerge    C:\Program Files\KDiff3\kdiff3.exe
whole_copy         xcompare  C:\Program Files\KDiff3\kdiff3.exe
whole_copy         xmerge    C:\Program Files\KDiff3\kdiff3.exe
z_text_file_delta  xcompare  C:\Program Files\KDiff3\kdiff3.exe
z_text_file_delta  xmerge    C:\Program Files\KDiff3\kdiff3.exe
z_whole_copy       xcompare  C:\Program Files\KDiff3\kdiff3.exe
z_whole_copy       xmerge    C:\Program Files\KDiff3\kdiff3.exe

The clearcase reports that come out of the box only let you find out the files that have changed between 2 labels. What if you haven’t applied the other label yet, or you are writing release notes and the official labelling hasn’t taken place yet?
If you have applied a label, how do you know which files have changed since then.

Open a command line and switch to the view and directory path you are interested in. Issue the following command:

cleartool find . -cview -version “!lbtype(MY_LABEL)” -print

where:
‘.’ is from the current directory,
-cview is current view
-version “!lbtype(MY_LABEL)” is look for versions without a label called MY_LABEL
-print is what to do with them.

Seems like an honest question, however the Project Voldemort website doesn’t actually tell you. Their page describes what features it has but doesn’t explicity say what it is. The Project Voldemort web site doesn’t have any email address of any of the members to ask questions, it only has an mailing list to which you can post questions.

After a bit of hunting, in fact far more hunting that I would have expected I came across this article which explains what Voldemort actually is. It even mentions why the project is called Project Voldemort.

http://www.bigdatabaselist.com/wiki/Project_Voldemort

Prehaps they should read my article on clearly defining what a project does. “The whats and whys to creating project descriptions“.

I’ve been doing work with the SpringFramework now for about 3 years. It has been a very steep learning curve - occasionally I feel like I’m rock climbing!

I started off using SpringIDE which is an open source commercial free Eclipse plugin which can aid the development of Java EE projects that use Spring.

The difference between SpringIDE and Spring Tool Suite is small but subtle. SpringIDE is an Eclipse plugin where as the Spring Tool Suite is an entire version of Eclipse pre-configured with all the plug-ins SpringSource thinks you need. It even has a Spring Source splash screen when it is loading.

In early 2009, SpringSource (the owners of the Spring Framework) decided to change the licence agreement of Spring Tool Suite (STS) so that it could be made freely available for development and internal business operations to use with no time limits.

I’ve been using STS for a while and I recently needed to report a bug against it. But could I find where to do it? No. I searched for a couple of days and eventually had to ask in the forums. So I write this blog to help anyone else who gets lost down the rat runs of confusion between SpringIDE and STS.

The big problem with reporting bugs is where do you go to do it. SpringIDE and Spring Tool Suite are both tightly coupled to Eclipse, they both have JIRA issue trackers, they are both tightly integrated into Spring and they both have Spring personnel on the support team. I suspect that in the long term SpringIDE will die as STS has loads of extra value adds and is considered the standard eclipse plugin.

So to find where to report bugs:

1. Load your Eclipse environment
2. In the menus navigate to Help -> About Eclipse
3. Click the green SpringSource icon, which opens the About Eclipse Feature window
4. Click the link for the product page: http://springsource.com/products/sts
5. When the web page loads in click the link for Bug and Enhancement Database in the Related Content section

if it ever disappears again from the Related Content position (like before) then you will have to hunt around for it which was the problem before. So here it is: https://issuetracker.springsource.com/browse/STS

For completeness you can report bugs against SpringIDE here:
http://jira.springframework.org/browse/IDE/

According to Christian Dupuis, who is the Spring bod who looks after the SpringIDE and STS, you can raise JIRA issues on the STS Jira for both SpringIDE and STS.

NSIS is an open source installer builder which works under Windows and Unix.

One of the problems with using macros/push/pop is that the quotes can conflict with each other. To avoid this I’ve found that standardising your quoting is important in order to avoid problems especially with nested calls.

The example below shows how a perfectly reasonable piece of NSIS code might unexpectedly not compile. Can you spot the mistake?

Code:

The doMessage is a macro which is substituted and not called, so the translations go thus:

${doMessage} “hello it’s me”

!insertmacro doMessage “hello it’s me”

MessageBox MB_OK ‘hello it’s me’

As you can see we have an invalid call to MessageBox because there are unmatched quotes. In order to overcome this problem the caller must know the nature of the quotes inside the code which is being used, and delimit the quote in such a way that it survives the invocation. In this case we must add an additional backslash which itself must be delimited to survive the first set of parsing. The section must be changed to:

Code:

so that by the time it gets translated we have:

MessageBox MB_OK ‘hello it\’s me’

Most people use double quotes to surround text because it allows you to use single quotes more easily.

However, there is a big problem if you are using NSIS and Windows. Bill in all his wisdom created DOS which has the most ridiculously complicated syntax when it comes to handling quotes [try typing cmd /? if you don’t believed me!]. Then he said you could have spaces in file names which you can only delimit by wrapping in double quotes.
Anyway what the hell does this have to do with anything? Glad you asked. In order to create an NSIS macro that leads to the ability to run a program under Windows you need to preserve double quotes all the way to the end, which means you can’t use double quotes as a parameter wrapper. So consider this code:

Code:

If you standardise your delivery quotes to always be a single quote and wrap out going calls in single quotes you should be able to avoid a lot of the headaches associated with un-terminated quotes.