Java Project Dependencies for the IDEless
For the sake of this post let’s just assume that my desire to be write java in a text editor, and not an IDE, is justified.
My text editors of choice are first TextMate and second emacs. I use TextMate when I have the code local and emacs when not. I won’t run VNC or X Windows in order to have a UI to edit remote files. I have no tolerance for latency nor dependency on network connectivity when editing text. This is when I use emacs and most importantly screen so that if my connection dies it will be there when I reconnect.
I took a vacation from java for about a year and was quite the happy developer. As of late I’ve been back in that world. I built up an affection for TextMate and its simple expansion capabilities and wanted to give editing java in it a try. I quickly realized that I had my work cut out for me. On top of that my friends/coworkers think I’m a bit insane which I cannot deny. But I was up for the challenge and have reached a point where I’m happy, not elated but happy. There were multiple pieces of functionality that I missed but I’m only going to focus on one of the big ones here.
One of the basic IDE features is the ability to view the source of your dependencies. By that I mean I the ⌘⇧T Eclipse shortcut that allows you to view the source of a java file of a dependency jar. When writing java in a text editor without code completion this felt required.
Since it’s debut I’ve been intrigued by MacFUSE (and of course FUSE itself). The basic idea is that you can make a file system out of anything without hacking the kernel. I was hoping to see a shift back to the file system enabling users of any editor or command line util to have some of the benefits provided by IDEs. Unfortunately I’ve yet to see this happen in the java world (please let me know if you have examples). A file system seemed like a good solution to my problem plus it gave me a real world reason to play with something new.
As a result I created a file system. The odd thing is that there’s nothing to open source. One of the complexities of java development is some companies have developed their own package management system over the years for one reason or another. At work we have a system that caches packages and source locally. Because I have access to the source I wrote a file system that was essentially a symlink farm to the already expanded source. At this point there’s nothing to abstract and release publicly. If I see the need and find the will I might attempt it. Regardless, as a result I have the ability to grep the source of my dependencies and to browse them in anything that understands a file system.
My file system looks something like the following:
MyProject
|
\-> dependencies
|
\->MySourceCarryingDependency
|
\-> src
|
\-> com.company.package
|
\-> AClass.java
\-> BClass.java
Essentially, this is similar to the tree of dependencies you’ll see in Eclipse for a java project.
The steps I took to create this:
- Install MacFUSE.
- Install the fusefs ruby extension. (Required only to develop/run a ruby FUSE file system.)
- Created an ant task that wrote my project’s classpath to a file. This just generates a file name “.run.classpath” in the project directory.
- Wrote a FUSE file system that on startup reads this file, finds the dependencies, and generates the file system.
File system creation via fusefs is simple. If you look at the demo in fusefs you’ll get the idea. You need to implement the following callbacks:
- contents - array of directory and file names for a path
- file? - boolean that states if the path is a file
- directory? - boolean that states if the path is a directory
- read_file - contents of a file
What’s my point of talking about this without releasing source? Basically, for those of us who prefer text editor s and the file system you don’t have to give up your editor for an IDE, at least for this. Don’t get me wrong, many developers love their IDE and I’m not knocking them (IDEs nor developers). But for those of us who prefer something else we have options and maybe they’re not out of reach.
