Swapfile for my brain

Our build system at work is a little archaic, but there just isn’t any time to rewrite it with anything more modern. As a result, I have to do some elbow twisting to get eclipse running smoothly with it. One of these contortions has to do with organizing the third party libraries we depend on.I start off with a directory called ThirdParty, under which I have a top level directory for each third party lib we use, e.g. commons-logging. Each third party directory will then have a sub-directory for each version we use, under which will be the jars for that lib plus a src.zip and docs.zip which contain the src and javadocs for use in eclipse. I find it better to keep them as archive files as it makes checkouts from source control a lot quicker, and I only ever browse their contents from within eclipse, which has no problem doing so. The nice thing about using the version number directories is that then the ThirdParty tree can be excluded from tagging/branching/etc. Since we never delete from ThirdParty, and the build files which are versioned have the right version number directory they depend on, the sytem as whole ends up acting versioned.e.g.

• ThirdParty
  • commons-logging
    • 1.0.0
      • commons-logging.jar
      • commons-logging-api.jar
      • src.zip
      • docs.zip
    • 1.0.4
      • commons-logging.jar
      • commons-logging-api.jar
      • src.zip
      • docs.zip
  • commons-lang
    • 2.1
      • commons-lang-2.1.jar
      • src.zip
      • docs.zip
  • foo-bar
    • 3.4
      • foo-bar.jar
      • src.zip
      • docs.zip
      • deps
        • commons-logging.jar

If a lib has dependecies on other third parties, I simply stick those dependent libs in a subdir of the version called “deps”. I really should do some dependency checking like Ivy or Maven, but no current need as this system is more for my eclipse browsing needs than it is for our build system. Ideally, I would prefer to use Ivy and/or Maven for something like this, but they didn’t seem to have a way to specify the src/docs attachments. Someone please correct me if I’m wrong.Once this directory tree is all setup, then I run a bash script (genlibs.sh) in root of ThirdParty directory) to generate the xml files used by eclipse for defining User libraries, and attach this library to my project so that I can easily browse the src/javadoc for all our thirdparty libs. Since these files are generated, anyone in the team can also use them - we can’t check them in because eclipse has no way of abstracting out paths in the user lib file, so unless everyone has the same path to ThirdParty, it won’t work.Within eclipse preferences, Java -> Build Path -> User Libraries, import any of the xml files the script generated. The all.xml file has everything, and after importing one can delete and/or move items around to match the reality of how the libs are used in your project. Othewrise, an individual library file is also generated for each lib, so feel free to use those instead.Hope this helps others out, let me know if you make any improvements.

My two new favorite firefox plugins:

• firebug: Combines so much useful functionality that I used to use multiple plugins for before, plus more that is not avaiable elsewhere. Basically lets you dynamically see sections of your page (css, html src, dom, etc) when you mouse over, regardless of if that section was generated dynamically with javascript!
• Tamper Data: Lets you see request/response headers/data like the Live HTTP Headers plugin, but also lets you mess with the data before submitting it back to the server.

Was trying to use python interactively on the command line in OSX 10.4, and realized it didn’t have readline support (up arrow command history in interative python shell). Fortunately, google turned up the answer here. To summarize, running the following command in a terminal did the trick.

python `python -c “import pimp; print pimp.file“` -i readline

In my quest to get OSX working the way I want, I discovered that a number of the firefox extensions that I use don’t actually work on OSX. So I figured this would be a good opportunity to learn a little about mozilla extensions by debugging what was wrong with them.

In my quest to get OSX working the way I want, I discovered that a number of the firefox extensions that I use don’t actually work on OSX. So I figured this would be a good opportunity to learn a little about mozilla extensions by debugging what was wrong with them.

First off, I recommend you create a separate dev profile so that you don’t screw up your real profile while mucking around with debugging. There are also some other config variables documented at the mozillazine wiki, which are useful if you want to do stuff like editing extension files directly without having to restart firefox to have your changes take effect. To create a dev profile, I fired up the profile editor by running the command

/Applications/Firefox.app/Contents/MacOS/firefox-bin -P

Once the dev profile is created, run it and install venkman and the offending extension(s). I’m using venkman 0.9.85 on firefox 1.0.6.

/Applications/Firefox.app/Contents/MacOS/firefox-bin -p dev

You should probably install just the extension you care about so that it can be debugged in isolation, unless of course, one extension is interfering with another and you need to figure out why.

Now you are set to debug your extension, but first configure venkman to be able to debug extension files by unchecking “Debug->Exclude Browser Files”. You may also want to tell venkman to automatically break in javascript that causes an Error or Exception by checking the menu items “Debug->Error/Throw Triggers->Stop for Errors/Exceptions”. Not all errors/exceptions are bugs, so this may cause more noise than its worth - especially if you have a bunch of extra extensions installed in your dev profile.

There are already a number of tutorials that teach one how to use venkman, so I won’t go into that here. You should now be able to set breakpoints in your code and step through it whilst exercising your extension. However, if you want to be able to debug the initial load/startup of your plugin, you need to do a couple more steps.

First, relaunch firefox telling it to run just venkman, without starting a browser:

/Applications/Firefox.app/Contents/MacOS/firefox-bin -p dev -venkman

At this point, since the browser window hasn’t loaded, none of its extensions have been initialized either, so you can set a future breakpoint on the load of the extension’s javascript file and be able to step through it while it is loading. In my case, I chose to debug the Single Window plugin because it seemed small and simple enough for me to get my feet wet. I also find it essential because new browser windows take a long time to start in my regular profile because of the extensions I have installed, with Google Toolbar being the biggest culprit.
/fbreak chrome://singlewindow/content/singlewindow.js 1

Now, its just a matter of telling venkman to start up a browser instance, which you can do with the open-dialog command, and then stepping through whatever code interests you.
/open-dialog chrome://browser/content/browser.xul

BTW, I submitted a fix for the Single Window extension to its author, and it should be in the next version > 1.4. If you can’t wait, it was just a matter of saving the value of window.Startup at the point right before it was changed rather than saving it at initial extension load at which point it seems to be null on OSX:

Line 67: window.Startup = singwin.Startup;
becomes:
orig_Startup = window.Startup;
window.Startup = singwin.Startup;

While I love the Eclipse Open Type/Resource dialogs they have a serious deficiency when it comes to working with multiple identical projects (e.g. different cvs branches)

For example, say I have 2 projects, P1 and P2 which are identical except from different cvs branches. If all I have open is P1/Foo.java and I go to open Bar.java, the Open Type dialog does not respect the fact that I’m currently working on P1, and I have to navigate to the right project within the dialog instead of simply hitting enter. This is not only a waste of time, its also very easy to mistakenly open/edit the wrong file!

I would much rather have the the default project selection be the same project as the project for the file I currently have focused. See the eclipse bug I have open on this issue.

Anyway, this problem annoyed me one time too many, so I ended up writing replacement dialogs that do the right thing. These are basically copies of the eclipse classes into my plugin with some tweaks - gotta love open source =). They’ll be part of my sunshade plugin suite for the 3.1 release. The old dialogs will still be there, but you’ll be able to map the old key bindings to my replacements if you wish. The Open Resource dialog replacement is intelligent and makes the default project selection be the current project, but you can navigate to other projects if you wish. On the other hand, Open Type Dialog limits the entire view to the current project - its seriously complex and I haven’t dug in far enough to figure out how to get it to work like Open Resource does. Till then, I map ctrl-shift-t for OldOpenType, ctrl-shift-p for NewOpenProjectType, and ctrl-shift-r for NewOpenResource - you may like to do something similar.

I haven’t checked them into CVS yet as I wanted to try and get OpenType working correctly. However, if you are as annoyed with the old behavior as I was, feel free to comment and I’ll accelerate things. I’ll probably submit a patch to eclipse as well, but who knows when that will be accepted, and I wanted to benefit from the new behavior now =)