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.

Running Eclipse: Windows or Linux?

Well, I chose Linux, the Ubuntu Breezy edition. There's a Windows version, but I think Eclipse is better suited to the Linux environment, but I admit that's a personal opinion. In fact, I'm writing this with Open Office running under Ubuntu.

Installing Eclipse

There's an Eclipse that comes with Ubuntu. Well, I think you actually use gnome-apt-install. It's an icon on the top menu bar. I don't remember whether it's there by default or I put it there. You got to be root to run it. I was not happy with this Eclipse. It appeared to be missing source code, and one of the points of having Eclipse is to look at the source code, not to modify it, but to understand what's going on. I'm going to be interested in adding plugins, and books tell me I should look at source code when I do that.

I downloaded eclipse-SDK-3.1.2-linux-gtk.tar.gz from www.eclipse.org, placed in my directory /home/ted/Eclipse_downloads, unzipped with gunzip, then untarred with tar vxf. There isn't really any configuration. Untarring releases a bunch of files from the tarball, one of which is an executable called eclipse.

Where's the best place to install Eclipse? I don't know.

I run that executable without arguments. I'll add args later, but for now this is it.

Now there's a question of what java I'm using. Inside Eclipse. I can look at Windows-Preferences... and then on the right panel open up java and select Installed JREs. I chose the Sun JDK, which I donwloaded from Sun a while back. I'm not sure what the other JVMs are. One came with Ubuntu, and it doesn't work well with Eclipse. If I use the original java, I can make java programs OK but cannot stop at a breakpoint. I talked with Bill at Padnug about this, and he says this is a known problem, but it's not clear whether it is a java or an eclipse issue. Let's see if I understood this correctly. The JVM signifies when it reaches a breakpoint and some JVMs do it differently than others. Eclipse does not recognize all the variations.

One of my books (I got a bunch on Eclipse that I read all at once; this one is eclipse Distilled by David Carlson) says that “you might have several version of java installed on your computer and you should use the -vm option to specify the one you want to use.” Well, I don't. But the Eclipse IDE itself is telling me what java I'm using.

Notice the line on top of the console window. It says /usr/lib/j2sdk1.5-sun/bin/java, the Sun version I installed.

Also, my command window shows java goes there.

ted@halibut:~$ which java

/usr/bin/java

ted@halibut:~$ ls -l /usr/bin/java

lrwxrwxrwx  1 root root 22 2005-12-26 15:32 /usr/bin/java -> /etc/alternatives/java

ted@halibut:~$ ls -l /etc/alternatives/java

lrwxrwxrwx  1 root root 30 2005-12-29 13:46 /etc/alternatives/java -> /usr/lib/j2sdk1.5-sun/bin/java

The same links work for javac.

Looking at the Eclipse Source Code

So this is how I did it. I'm reading Contributing to eclipse by Erich Gamma and Kent Beck. This is an excellent book, written by two famous programmers, but it is somewhat out-of-date. Its examples come from an older version of Eclipse, and the screens show windows that we don't have any more.

So this is what I did. Choose File – Import ... Then, select External Plug-ins and Fragments and click Next. Choose to import as Binary projects, which makes the projects read-only. You can still look at the source for binary projects, and you want to look at that source when you add a plug-in of your own. But you don't want to modify any of that source. Click Next again and select Add All ...

The in the Package Explorer, you see a lot of projects. You can use the dropdown menu in the Package Explorer to filter out these plugins and see only your own projects if you want to. But if you leave then there and navigate to a class in one of the plugins, this is what you see. Yes, you can cruise the source code, which is just what I want to do.

This is org.eclipse.debug.core. Then open up org.eclispe.debug.core_3.1.2.jar. Then under org.eclipse.debug.core, double-click DebugPlugin.class. The book says to use Navigate – Open Type and put in *, but I haven't had luck with that. The resulting window always shows OK as disabled.