Swapfile for my brain

I finally got around to updating my sunshade suite of eclipse plugins to run under eclipse 3.2.

To install, either plug the update site http://sunshade.sourceforge.net/update into eclipse’s “Help->Software Updates->Find and Install…”, or grab the full release from the Project Page and unzip it into your eclipse install directory or extension location.

Some basic documentation can be found at sunshade’s sourceforge home page

Changelog:

v3.2.0

Updated for eclipse 3.2

Added pipe from stdin to EclipseClient/Server

Added a builder plugin for my custom external tools builder (seedocs)

Fixed some bsf bugsAssorted bug fixes

v3.1.0

Updated for eclipse 3.1

Added server for fileopen for opening files in eclipse from commandline

Fixed log4j logging

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.

So, the eclipse performance on OSX was bugging me enough that I decided to try getting the eclipse GTK port running on OSX. The idea being that eclipse GTK runs pretty good on linux these days, so it should run similary well on OSX.

So, the eclipse performance on OSX was bugging me enough that I decided to try getting the eclipse GTK port running on OSX. The idea being that eclipse GTK runs pretty good on linux these days, so it should run similary well on OSX.

Well, I was partially right. While it does run a lot faster than carbonized eclipse, there are a bunch of UI glitches that make it less usable for me. I’m hoping that if I document how I got it to work, maybe someone else can do the grunt work of trying out other alternatives that may fix the problems I am having. If you do, I’d appreciate the feedback.

First some pre-requisites. You’ll need to have a X server installed and the gtk libraries. I’m using the Apple X server (from OSX 10.4 install CD), and used fink to install all the gtk libraries I needed - in fink-commander, install everything with gtk+ in the name.

Next, get the eclipse linux-gtk 3.1 release and extract it to the directory of your choice (I used /Applications/eclipse-swt. This makes for an easy starting point since I didn’t feel like creating a new eclipse port and building from scratch.

There are really only 3 native components we need to worry about replacing, two of which are optional. The launcher we can bypass by using java to launch eclipse, and the org.eclipse.core.resources.linux only improves filesystem performance, defaulting to java.io.File if the native library is not present. The only one we really need to do anything for is the swt plugin. Fortunately, one of the eclipse developers recently ported/compiled the swt-gtk libraries for OSX, and you can fetch them from here.

Now you need to extract the swt plugin into a directory of the same name:

cd <eclipseInstall>/plugins; unzip -d org.eclipse.swt.gtk.linux.x86_3.1.0 org.eclipse.swt.gtk.linux.x86_3.1.0.jar

Remove the jar when you are done. Next you need to copy the osx-swt-gtk *.jnilib files from the above download into the directory you just created. I also deleted the existing binaries from that directory to be safe.

Finally, to run eclipse, you have to use the command line to run the java launcher directly. Make sure your X server is running, and the shell you are running from has the DISPLAY=:0 environment set. Then the command to run eclipse is

java -cp <eclipseInstall>/startup.jar org.eclipse.core.launcher.Main -clean -os linux -ws gtk -arch x86 -vmargs -Xmx512M

Note that I specified linux/gtk/x86, which seems counter intuitive, but thats the download we started from. Also, you probably don’t want to use an existing workspace, so pick an empty directory for your workspace location.

Now, assuming I didn’t miss anything (let me know if I did), your eclipse should fire right up using swt-gtk.

Issues I have

• Dialogs are all weird sizes/layouts, no idea how to fix them. Especially broken is the Find dialog (ctrl-f in an editor)
• Related to dialogs, but more annoying to my work habits, the ctrl-f6 used for switching between editors is unreadable because its too small.

Things to do

• Billy Biggs (eclipse guy who made the binaries) mentioned on eclipse.platform.swt newsgroup that fonts may be to blame, could be worth investigating.
• Try a different X-server, maybe a more recent build of Xfree/Xorg from fink or darwinports would fix some of the dialog issues
• Try some different window managers - I only tried the built in apple one and gnome-metacity, both exhibited same funky dialogs
• If other issues are resolved acceptably, might be worthwhile to do the full macosx/gtk/ppc port using the eclipse source distribution. At the very least, the core.resources binary from linux/gtk/x86 should be recompiled in the same way swt libs were so that we don’t suffer when doing a workspace refresh.

Dog slow!

A couple of things I’ve learned

• Stop spotlight from indexing eclipse workspace.
• Bug in Tiger/Java that causes eclipse to slow to a crawl after launching a (java?) app. This was really killing me because I have a builder than runs an ant script, so my performance was always in the shitter. Better now that I’ve removed the builder, but the UI still seems very slow - especially when using Apple-F6 to switch between editors. I hear that disabling a bunch of things like CVS decorators make it better, but haven’t tried it yet cuz I like those things. See this eclipse bug for details on the Java performance problem under OSX (boy I sure wish I could find a torrent for 10.4.3 build 8F8)
• I’ve been experimenting with getting eclipse to run with GTK bindings under OSX. I;ve bgotten it working, but it has too many issues to make it suitable for me. I’ll publish the details in another entry if anyone comments that they are interested. Maybe someone else can take up the torch and get it working well.

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 =)