* Sensationalist headline inspired by previous posts

Eclipse is my IDE of choice, as you’l probably have noticed from some of my previous articles. I had been wanting to write an article about why I use it (and why I switched to it), but kept putting it off. Recently, Matt Mullenweg wrote about his problems with Dreamweaver, and this perhaps prompted me to organize my notes on why I’ve chosen to use Eclipse. Don’t get me wrong - I’m not advocating that you immediately switch and throw out your current editing tool (the headline above, as noted, is purely for sensationalism) - but rather I’m just urging you to consider Eclipse for your next project.

Changing Gears

Like many, before switching to Eclipse I had been using a pure text editor, Ultraedit, for most of my web-development activities. Ultraedit seemed fine for most things, offering basic features like code highlight and autocompletion. However, it lacked a certain finesse when it came to dealing with larger projects. For example, if you’d defined a class, its members wouldn’t be available for autocompletion. Something else was needed. I finally decided to take the plunge, and switch over to Eclipse for all my development towards the end of the summer last year.

Some might wonder why I was even using a text-editor in the first place for development. For those coming from a traditional programming/development background, the idea of not using an IDE (Integrated Development Environment) is silly. This is because a lot of programming languages are compiled, and in this case, it just makes sense to use an IDE since it’s easier to write code, compile and debug using one tool instead of multiple ones.

However, for scripting languages, especially those meant to run on a web server, one can “get away” with not using an IDE quite easily. This is because the scripts are not run standalone but are almost always executed in the context of a web server; thus you’re usually editing code that you then run on a development web server, without the need for a special tool like a compiler. Additionally, it’s easy to view the output using any web browser. These reasons are what allowed me to persist in using a text-editor for so long.

No turning back

However, once I started using Eclipse, I was hooked. I downloaded Eclipse PDT (PHP Development Tools), which is basically a version of Eclipse bundled with the tools/plugins necessary for setting up a PHP development environment. Besides offering everything Ultraedit did, it also offered nice features like easy ‘Todo’ lists, (just type ‘todo’ anywhere in a comment and it’s automatically indexed by Eclipse into a list), code completion for built-in PHP functions and your own as well as a multitude of other advanced features that IDEs have. Oh, and it’s also FOSS. (Free and Open Source Software)

However, perhaps the best part about Eclipse is its robust and well-supported plugin system. This allows Eclipse to pretty much assume any feature that someone is willing to write a plugin for. This is what really sold me on Eclipse, because this almost makes its abilities endless. Some of the plugins I use are Subclipse for SVN integration, Mylyn for Trac integration and JSEclipse for JavaScript editing. This is part of the reason why Eclipse is the basis for many other IDEs out there.

Some other nice features are the ability to link the IDE in with the Zend Debugger, thus allowing for proper debugging sessions with PHP.

Spoiled

However, I’ve been pampered somewhat and have found a few things to complain about, at least when it comes to Eclipse PDT. I use Eclipse JDT (Java) a work and its advanced refactoring abilities are a feature I find myself wanting in the PDT version. Have you ever found yourself wanting to rename a variable to something more descriptive but putting it off because you’re afraid you’ll mess something up by forgetting to change the name somewhere?

With some IDEs, you’re left having to just do a search-and-replace in order to accomplish what should be a trivial name refactor. Even if your editor supports regex searches, things can still be tricky - what if you’ve used the same name, but in a different context, and thus shouldn’t change the variable there? The point is, the process still has to be human-supervised and is tedious. With Eclipse JDT’s advanced refactoring, you can rename the variable once - and the IDE is smart enough to know where else to change it to keep the code consistent - very neat, and I was amazed when I first used it. Other refactoring abilities include extracting methods out of blocks of code in order to clean up lengthy methods. All of this makes your life 10 times easier and allows you focus on real programming rather than annoying tasks.

However, Eclipse PDT doesn’t support this for PHP code, yet. I hear that it may be supported in a later release, so I have my fingers crossed. Perhaps accomplishing these refactoring tasks is easier in Java because of its compiled nature or because the JDT project has received more attention. It’s definitely possible in PHP, as some IDEs, such as the Zend Studio (which is based on Eclipse) support this ability. Zend Studio, however, is a commercial solution and I haven’t tried it out yet.

Nothing’s perfect

Eclipse does have its downsides as compared to a traditional text editor. First of all, it’s a memory hog - though most IDEs are. I have regularly seen Eclipse eat up 300-400 MB of RAM if I’ve been using it for a long time. However, it should be noted that I have not had it crash once, so it’s been rock-solid as far as stability goes. Nonetheless, I recommend you to have at least 2 GB of memory if you really want to use it properly, since you’re likely to have other programs open. This is especially important if you’re running Windows Vista. RAM is quiet cheap nowadays, and you can easily pick up 2 GB for $50 or less and upgrading is a painless process, so there’s no reason not to.

Finishing up

Eclipse has changed my life. Okay, so perhaps I’m exaggerating a bit. But, I can say that development, at least for me, would be much harder without Eclipse. If you’re still using a text editor for development, I urge you to give Eclipse a try - just for 30 days, and see how you like it. I don’t guarantee results as good as mine, but you may be pleasantly surprised.

I won’t go into too much detail about the features since I wanted to talk about integrating the Eclipse plugin Mylyn with a Trac setup on Assembla. There can be some issues getting things to work so I’ve outlined what I did to get everything running nicely.

Background: Mylyn

Mylyn is an excellent task-management plugin for the ultimate IDE, Eclipse. I have been trying it out for a variety of things, since I was trying to find something better than just text files for managing various tasks lists. However, Mylyn does much more than just task management as it helps to streamline your work environment with “context”. I haven’t started using these advanced features though, but what really caught my eye was the integration Mylyn offers with various issue-tracking services such as Bugzilla and the aforementioned Trac. This is accomplished by various “connectors”, with each connector being specific to one of the issue-tracking systems.

The Problem: XML-RPC Integration

Integration of Mylyn with Trac allows you to view, create and edit tickets in a Trac repository from within Eclipse. To accomplish this, there are two levels of integration, the first being simple web-based access. This is the more primitive of the two and has been around for longer. Basically, items are still edited from a web browser; the only difference is the web browser is spawned within Eclipse. This isn’t really ideal and doesn’t offer a real integration.

The second uses an XML-RPC interface to send/receive data and thus offers proper integration with the Eclipse environment. However, when trying to connect to my Trac setup on Assembla with this choice, I ran into a lot of intermittent 404 (not found) errors. Basically, synchronization was very flaky and by no means usable.

The Fix

I did some searching and found this page on the Assembla site where other users had experienced the same problem. Scrolling through the comments brought me to this nice fellow’s explanation of the problem, where a screencast was provided showing how it had been fixed.

Basically, these are the steps I did to get Mylyn XML-RPC integration with Trac working.

1. Enable the XML-RPC plugin

   Go to your Trac site, then click on Admin. On the left sidebar go to General > Plugins. There should be a section called TracXMLRPC; click to expand it. You might as well enable RPC access for all of the options provided, though I’m not sure if this is necessary. Here’s a screenshot.

   

2. Enable XML-RPC permissions

   After that, you need to enable permissions for XML-RPC access. Go to General > Permissions on the sidebar. In the “Grant Permissions” area, add a permission for “XML_RPC” for “@editors“. Using “@managers” for the subject might also work/be needed if you’ve setup access for those users. This is the basically what it should be:

   

3. Ensure there is at least one ticket in the system

   For some reason, I had weird errors when trying to synchronize/connect to a Trac repository with no tickets. This was corroborated by the fellow who originally found the solution to this problem. It’s a minor issue though, just click “New Ticket” and create a placeholder.

4. Add Trac to Mylyn

   This step’s simply enough; though some suggestions recommended using http://<domain_name_to_assembla_trac>/<space_url_name>/login/xmlrpc as the URL, I simply used http://<domain_name_to_assembla_trac>/<space_url_name> and it worked fine. Remember to use XML-RPC as your access type or you won’t get proper integration.

   

After that, you should be able to properly connect to your Trac repository using the XML-RPC option of Mylyn. Then, you can finally enjoy proper Trac integration in Eclipse!