Posts tagged with “”

Friendly Project Names in Komodo Edit

For several years now, Eclipse has been my primary IDE. I’ve used it to write in a number of languages on a number of platforms and was more or less happy with it. In the last six months or so, the scales of justice began to tip away from more and towards less until a couple of months ago when I finally hit my breaking point. I decided that I’d had enough of trying to dedicate enough system resources to keep Eclipse happy. I’d had enough of trying to keep my installs on several machines using several operating systems synced up properly. I felt like Eclipse was taking over my life rather than making it easy.

I started looking around with only a couple of key requirements:

  1. Responsive. Not necessarily fast, just responsive.
  2. Cross platform. I’m cross-platform and I need my key software to be cross-platform too.
  3. Power user friendly. By that, mostly I mean a rich set of keyboard shortcuts and snippets.
  4. Free-ish. I’m happy to pay for good software, but I’m not willing to plunk down hundreds of dollars if there are almost-as-good options.

After trying a number of IDEs and text editors, I finally settled on Komodo Edit. It’s a text editor that’s lightweight and snappy the way that a text editor should be, but it has just enough IDE-like features to meet my minimal needs. It met all of my needs.

For me, one of the huge tipping points was that it is a project-based editor. I loved that particular metaphor once I started using Eclipse and it’s not something you see in a lot of text editors so I was happy to get that support. What I didn’t like was that, unlike Eclipse, I couldn’t enter a “friendly” name for my projects. Eclipse has its .project files and Komodo Edit has a projectname.kpf file, but in the latter there was no way to set a nice, human name for each project. Cracking open the .kpf project file showed me that it’s just an XML config file and that there’s a name attribute on the project root element, but changing that changed nothing.

I asked about this on the forum and one of the developers suggested that I enter an enhancement request. I did and, to my surprise, a patch was made available the same day – within an hour, if I recall correctly. Since doing so, the change has been rolled into the latest version (v5.1).

To give your Komodo Edit friendly project names that will show up in the project explorer:

  1. Create a project (if one isn’t already created).
  2. Open the .kpf file in a text editor.
  3. Set the value of the name attribute to the friendly value of your choice.
  4. Save, close and restart Komodo Edit.

Here’s what one of my .kpf files (scratchpad.kpf) looks like:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Komodo Project File - DO NOT EDIT -->
<project id="714c52ec-687a-0241-b5ef-eb09952b79d5" kpf_version="4" name="Scratchpad">
<preference-set idref="714c52ec-687a-0241-b5ef-eb09952b79d5">
  <boolean id="import_live">1</boolean>
</preference-set>
</project>

Stop Frequent Eclipse Crashes

I spent the better part of last weekend configuring my new work laptop to dual boot into Linux – 64 bit Ubuntu 8.04 (Hardy Heron) to be precise. A critical component of my install is Eclipse. To my aggravation, I found that when I was working Eclipse would crash with some meaningless error message about every 5-10 times I saved. I saw the same error – and crash – when I tried to refresh the explorer or perform a Subversion update using Subversive. For all intents and purposes, this made Eclipse unusable so I searched. And searched. And searched. And…you get the idea.

Eventually I stumbled on to a JVM bug and a related Eclipse bug that, frankly, sounded only marginally like what I was seeing (and that’s probably being generous). Nonetheless, desperation had set in and the JVM bug offered a workaround that was simple and would be easy to rollback so I decided to give it a shot. It worked.

Sometimes it’s better to be lucky than good. If the workaround had been more difficult I probably wouldn’t have tried it, but it wasn’t (more difficult), I did (try it) and it may be worth trying for anyone who’s experiencing similar issues. It’s as simple as adding the following lines to eclipse.ini:

-XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/DataTreeNode,forwardDeltaWith
-XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding,<init>

These lines should be added in the -vmargs section. For what it’s worth, I’m running java version 1.6.0_06 and offer the usual disclaimer that YMMV.

Remove Console Output Limits in Eclipse

I run a lot of builds. I run the vast majority of those builds directly within Eclipse taking advantage of its integration with Ant and some of those builds are large. More accurately, some of those builds are verbose, whether it’s because I’m explicitly documenting what’s happening for later debugging or whether there’s a lot of output from a given task (svn export is a perfect example) that’s being displayed. Sometimes there’s so much output that the console’s buffer discards a portion of that output and prevents me from debugging effectively if a problem arises.

By default, Eclipse limits the console output buffer to 80,000 characters, but this can be changed easily enough. In my case, I like to remove the limit all together:

  1. From the menu bar, go to Window > Preferences > Run/Debug > Console.
  2. Uncheck the box labeled Limit console output.

With that limitation removed, I can access the unabridged version of my build output. This setting is not specific to Ant, of course. It will remove the buffer size limit for any action that directs output to the console.

Run Eclipse-Installed Ant from the Command Line

In the midst of my transition to Linux at work, I’m also working on updating the Ant build script templates that I’ve used for years to deploy every project I/we develop. When I built my Linux box, I installed Eclipse using Pulse. More often than not, I run my Ant scripts from within Eclipse (I love that integration), but from time to time it’s expedient, for one reason or another, to execute a build from the command line.

In previous lives, I’ve installed a standalone copy of Ant and used that for command line execution, but this time I was feeling thrifty. Clearly there’s an Ant executable baked right into Eclipse, which I already have installed, so why can’t I just use that one? Well, no reason, except that I didn’t know the path to said executable. So I dug around.

As you might expect, this is not a difficult problem to solve. I found my Ant root directory by looking in Eclipse under Window > Preferences > Ant > Runtime. On the Classpath tab, the first expandable group is named Ant Home Entries. Expand that to see all of the libraries that exist in the native classpath or, more importantly for this purpose, to see where the Ant home directly exists. To find the Ant home directory from these library paths just drop the /lib/[…].jar part of the library path. On my Pulse-installed instance, doing that leaves me an Ant home directory of /home/[user]/Applications/Pulse/Common/plugins/org.apache.ant_1.7.0.v200706080842.

Once you know the home directory, all that’s needed is to set a couple of environment variables and you’ll be able to run the Eclipse-installed instance of Ant from the command line or Eclipse.

For Linux and Mac users, edit your shell’s login script. In my .bash_profile, I added the following lines (syntax will vary for other shells):

export ANT_HOME=/home/[user]/Applications/Pulse/Common/plugins/org.apache.ant_1.7.0.v200706080842 export PATH=$PATH:$ANT_HOME/bin

Once you’ve saved and quit the editor, ensure that you “source” your modified script (or exit the terminal and return or even just open a new tab) to activate your changes for the current session:

$ source ~/.bash_profile

That’s it. To test, just type “ant” at your shell prompt. Ironically, Ant is alive and well if you get a failure message:

$ ant Buildfile: build.xml does not exist! Build failed

That’s it. Linux and Mac users can go on about their day.

Windows users will have to set/update the ANT_HOME and PATH environment variables in Control Panel > System > Advanced > Environment Variables. Windows users may also have to restart in order for their changes to stick unless they also set those values at their own command prompt for use during the current session. For the values to persist beyond the next reboot, though, the first method is required.

Powered By Pulse

Or not.

On the long flight back from Bangalore, I settled in to do some work. The work was local and I use Eclipse as my IDE so I was ready to rock.

Or not.

For a while now, I’ve been trying Pulse to manage my Eclipse installs across multiple computers. I’ve had significant, but not critical, issues in other areas that I won’t go into here, but because I’ve got a few active projects on my plate, I didn’t want to take the time to rebuild my entire Eclipse installation. On the flight, though, the camel’s back was broken.

Read More »

← Earlier Posts Page 1 of 2