I downloaded Eclipse 3.1.2 and for the last few days have been trying to become familiar with it. I'd like to say becoming proficient, but that's a while yet in the future. I had put it aside for a few days because I was busy studying for and taking a Microsoft Certification Test (70-320, XML Web Services, .Net Remoting, etc.) This is an old test, not part of their new program, but I had been reading about these topics for a while and thought I should get it out of the way. It was a hard test, I thought, probably hard for me because my knowledge of these topics comes mostly from books and not experience. I know it's silly, but I put the certificate I got on my wall; it took a bunch of effort, and I'm proud of it, so don't laugh.

I decided to run Eclipse under Linux (The Ubuntu Breezy edition) because I thought the spirit of Eclipse was more open-source Linux than proprietary Windows. However, the main book I'm looking at assumes you're running Windows. Alas. It's a good book, though — eclipse Building Commercial-Quality Plug-ins by Eric Clayberg and Dan Rubel. The book is the second edition and also describes Eclipse 3.2. Now the latest download I got from www.eclipse.org was 3.1.2, and I'm sticking with that. The site discusses a release candidate (RC4), but what I'm doing right now is pretty simple, and I'll stay with 3.1.2 for now. Yes, I will upgrade, but I'm not ready to yet. The same is true with Linux. The new release Dapper Drake just came out, but I'm still running Breezy.

I'm scheduled to give a talk about Eclipse and plug-ins at  Portland Code Camp v2.0. This looks like a fun event, and it's free! I went to v1.0 last year. Check it out at http://pdx.techevents.info/codecamp/2/Default.aspx  .  So this is my reason for not upgrading right now. I have some stuff to prepare and don't want to risk getting my computers stuck in an upgrade. But upgrading is good, and I will do it, probably some time in August.

What I wanted to do was first give an introduction to Eclipse, intended for people who haven't used Eclipse before. You know, you've installed it and now what do all those menus mean and how can you set up a development environment and write a simple project. Then, I wanted to write a simple plug-in and show how to add it to the Eclipse environment.

Yesterday, I spent a bunch of time with CVS. Now I know this isn't the latest and hottest version control system, but my interest was not it using the latest and hottest but to understand how Eclipse integrates with version control. CVS is tried and true, and so my focus could then be on the integration of Eclipse with version control and not on the version control itself.

I discovered that my Ubuntu system didn't have CVS. Strange, I thought. In the old days, you installed Linux and it had everything, more than you wanted, more than you'd ever use. Today you get a stripped-down version (Breezy didn't even come with gcc) and then add what you need as you need it. Better, I think; you end up with a cleaner system, but it requires more effort.

Anyway, with Ubuntu, get eclipse through the Synaptic Packet Manager. Click Apply and it downloads and installs. I thought it curious that the installation asked me to load my original Ubuntu CD, but I save those things, so it was OK.

I've used CVS before, or course, but it's been a while. I dug up an old (but still good) book called Open Source development with CVS by Karl Fogel. I think it's like the CVS classic. (There's a newer edition, and he has a co-author.) I also found directions on the CVS wiki, http://ximbiot.com/cvs/wiki/index.php?title=Main_Page

Here's a short description of what it takes to get CVS working under Ubuntu. The first thing you got to do is make a repository. Remember that the repository is for CVS, not you; it's not a subdirectory of your working directory.  I looked at the directions in Fogel's book and choose to make the repository at /usr/local/cvsroot. I also looked at the Ubuntu forum, and apparently this is not the standard location. But the location doesn't really matter; it just has to be something. I became root and issued the command

cvs -d /usr/local/cvsroot init

Here's the result of that command. Note that a directory called CVSROOT is created under /usr/local/cvsroot, and there are a bunch of CVS files put there. One should leave them alone.

About permissions. CVS needs write access to the repository. Fogel recommends (and I did this) that you make a group of CVS users and then assign that group to the repository's group ownership and permissions.

Ubuntu has a nice GUI for making groups.

What I found, though, was that I was not a member of that group (checked with the groups command) until I logged off and then on again. I'm sure there's a way of forcing membership without logging off/on, and I fiddled for a while without success.

Also, it's more convenient to set an environment variable called CVSROOT to the repository's location, and the best place (I think) to make that definition is in .bashrc if you're using the bash shell.

Note that I also set an environment variable CVS_RSH, but that's another story. It turns out that this is critical for getting Eclipse to talk with CVS using the method I chose, but that's another story.

The next step was to get a little code project and see if I could check it in and out of CVS successfully. You know, eventually I want to do this with a Java project loaded into Eclipse, but for now, I just wrote a C project under my home directory. I wanted this project to be a little more than “hello world,” though. This meant putting together a toy application that would pull utilities from one directory and have a main program in another.

Now I know there are fancier ways of building applications these days, and I want to look at some of those when I get into Eclipse. But for this test, I relied on that old standard, make. I needed a recursive make and honestly thought I could remember how to do that, but my first attempt failed. I had to find a  book that I discovered years ago, Managing Projects with make by Andrew Oram and Steve Talbott (yes, I still had it).

To add the project to CVS, first delete all executables and and object files and import the project.

Here's what results.

The key thing to mention here is that although the project is imported, the remaining source files are not a CVS working copy. For example, if you try

cvs log ted001.c

CVS won't know about ted001.c in spite of the fact that it's a member of an imported project. You got to check out the files. Before doing this, I deleted all the source in the sample_project directory under my home. Yes, I was paranoiac enough to make a backup. Then, I checked out the files with (be sure to cd to the parent directory of sample_project before checking out).

cvs checkout sample_project

Then,

cvs log ted001.c

shows two entries: the initial import and the initial revision. I made a trivial change to ted001.c, then tried cvs log ted001.c again and saw the change displayed on my screen. So it appears to be working.

The next task is to get Eclipse talking to CVS. I'm almost there. Getting Eclipse to recognize the repository was not as trivial as the books make it out to be. I'll describe what I did next time.