.::output >> /dev/null::.

This was something that I really wanted to blog about for a long time...

Last year I wanted to know a way to save sessions in Eclipse like I could for Firefox. For instance, Firefox allows you to save the open tabs and windows into a new session and restore that session in the future. That way if you ever need to recall a set of tabs for reference, they can be easily activated by restoring the saved session.

In fact, any decent, editor or IDE should the option to save sessions. Heck, Vim and Emacs have this feature out-of-the-box. Sessions are really useful when you have to work on groups of related files at the same time but don't want to have to remember which they are.

So why was there apparently no way to do this in Eclipse? Initially, I thought that Working Sets might be the solution. However, they only allowed you to group files into sets. They don't actually remember the editors that are opened and what state you were in. So Working Sets were not even a poor man's implementation of sessions.

Then epiphany struck! We could use the Mylyn plug-in to accomplish this. In fact, as you shall see, Mylyn can do even better than just saving sessions - it infers them automatically based on what you are doing! Mylyn comes installed standard now on Eclipse 3.3 and higher. In fact, the Mylyn view is even shown by default; it's not activated though.

Anyone who does not use sessions has a) an incredible memory, b) an inhumane ability to do context switching between tasks AND c) the luxury of not having to close his IDE ever. Or the developer just doesn't know that such an excellent tool exists out there...

This is Mylyn
I have readjusted my perspective a bit so that everything can fit nicely in a 800x600 window. The picture above shows the Mylyn view with some sample local tasks.

Activating a previous session
I am activating a previous session. By default, Mylyn automatically remembers the last context that you were in before closing the editor and will restore that.

Previous session restored
You can see that Mylyn remembers the files that were opened in that session and has restored them in the editors. The current active task (see the Task List view) has a blue bullet next to it. In the Package Explorer view, you can even see the other files that I might have referred to in a previous session but did not open in any editor.

Creating a new local task (context)
Mylyn allows you to create local task for your own use. With the proper server, you can also create sharable tasks in a Bugzilla or JIRA repository. That way, you can share the same session with yourself when you are working on a different machine or with your other teammates so that they can take a look at the same things that you are looking at.

Editing a local task (context)
You can easily associate other metadata with each task. In fact, Mylyn was originally created to be a task-oriented system. It allows you to split your work into little tasks to help you focus.

Deciding to show everything or just the active task
You can easily switch between showing all the files in the Package Explorer or focusing on the active task by clicking on the Mylyn button.

Mylyn has a whole bunch of other features. Some of the interesting ones include:

• The ability to share a context with different tasks. You can clone the current context and paste it into a different task.
• It cleverly remembers what editors and files that you have accessed and stores those into its session.
• It intelligently forgets editors and files that you have not looked at for extended periods.
• You are always in control - you can override the behavior easily and promote/demote certain files from sessions.
• It records how long you spent on each task so that you can actually report that figure with certainty.
• It's well integrated with different perspective and views in Eclipse. And it is constantly being improved upon.

Mylyn is great for helping you focus on your programming tasks. It stays out of your way for the most part but is easily accessible when you need it. Once you start using it, you really wished that every IDE out there (including the venerable IntelliJ) supported it.

I was reading the book Spring In Action in my attempt to learn about Spring. More importantly, I needed to know enough to be able to incorporate refactoring support for it as part of my project.

Unfortunately, the book had some typos which were actually technical errors. And this was just in Chapter 1! If you are trying to learn something for the first time and there are typos, you might not be able to detect it. And this can lead to hours of frustration....

Fortunately, IntelliJ has support Spring. And it detects the errors for you! So even if the technical reviewers did not detect the error, at least your IDE (a good one) can do it for you and save you time.

IntelliJ 7 has support for Spring. In this case, it detected that something was wrong with the xml configuration file.

It even offers the ability to correct the error!

I wonder if the error in the book could have been detected had the reviewers use a better tool. Or at least attempt to run it using some automated tool.

Refactoring Dynamic Code:

"These tools, along with the relatively small amount of Ruby code required to implement the desired features, made life easy during the first few iterations. With each new feature, however, the amount of refactoring required to keep the codebase clean increased. Although Rails' adherence to the DRY principle helped reduce duplication, each refactoring had to change numerous code artifacts. Some of the changes, admittedly, were needed to keep the code in line with Rails' convention-over-configuration philosophy.
Renaming an entity class, for instance, requires renaming the corresponding database tables, including other columns and indexes referencing the model's table, renaming the model class, changing the corresponding controller, helper classes, and every reference to the entity class in the views, as well as renaming the directory containing the view classes and templates. And, of course, you have to similarly rename the associated tests and all references to the model, controller, and views in the tests and fixtures."

One of the advantages of being under Prof. Ralph Johnson is that we are indoctrinated to think of programming as a series of program transformation. From the humble HelloWorld program (just think of when you are reediting the program to add some comments or change what gets printed out to the console) to more complex programs out there, almost everything can be viewed as a series of transformations.

Refactoring is as a form of program transformation. Refactoring is a process where you restructure your code without affecting its observable behavior -- where behavior is defined pretty loosely. Why would anyone want to do something like this? If you have never done refactoring before this might seem like a worthless task. After all, if you aren't modifying the behavior of the program, you aren't adding new features to it. And features are what the customer cares about, right?¹

Well, turns out that you refactor to make your code easier to understand. Code that is easier to understand is also easier to modify. So essentially, refactoring helps prepare your program for the next feature, and the next feature, and the next feature... that you want to add; making those features easier to add.

Certain refactorings can now be automated through an intelligent IDE. And IDEs have generally done a very good job of it -- until you being to cross the traditional language barrier. For instance, look at Rails. Rails is a framework that relies on Ruby, erb, Javascript, SQL, etc. When you perform a refactoring on your Ruby code does that refactoring percolated correctly through the entire program? If you rename a method in your Ruby code, will it change the name of the method to the new one everywhere that it was called before? Would it also be able to change the method call inside the erb file?

Furthermore, because Rails relies on the convention-over-configuration idea, it is desirable that your refactoring preserves those conventions as well. So now, your refactoring tool not only needs to know Ruby but it must be configured to understand the Rails framework itself! Renaming your Rails model should also make the appropriate changes to the controller and your erb file just because the framework expects them to be related by name in a predetermined manner. Failing to do so would actually cause your program to fail.

If another framework comes along, your tool has to be taught to function for that framework too. And a programmer might choose to use numerous frameworks together. How would you ensure that the refactoring tool would work for any combination of frameworks?

The point of this post is to illustrate the need for multi-language refactoring support. We can think of complex frameworks as basically an extension of the language itself. Frameworks have their own set of conventions to be followed. Following those conventions is essential for a framework such as Rails. For other frameworks, following those conventions would be desirable to make the code easier to reason about.

So the main challenge is how to capture those rules that a framework specifies so that our refactoring tool can understand them and make the appropriate changes toward the entire code base.

This is actually something that I spent two days on trying to get to work properly. There were a couple of variables that made this harder than necessary: the documentation on getting the latest version of Photran to compile was a bit out-dated (we need the latest version of the CDT from HEAD for the tests to run) and the fact that we are switching to Eclipse 3.3 which might not work well with all the plug-ins out there.

The plan was to run some metrics and code coverage measurements on the Photran code base. Using the data that we gathered we could evaluate sections of code that needed refactoring and/or testing. We could only use free tools since we wanted the students to be able to run them on their own computers. Naturally, if we did not have this major restriction we would have chosen some better commercial tools.

The State of Flow Metrics was the first one I tried but it does not do a good job. The UI and visual feedback were so bad that I did not even know if it was working. So, I ran the tool on a smaller project; it completed the analysis. However the information it provides is not presented intuitively. Instead it adds a little icon on the left margin of the editor that does nothing more than indicate that it had analyzed that method. Then the data is presented in the Problems view along with all the other errors and warnings. For small projects, this is fine but for larger ones with 100s (or 1000s like the CDT) of warnings, you cannot even determine which are warnings from the metrics tool (vs warnings from the Java compiler). So this is pretty much useless for large projects or workspaces with 1000s of warnings. It has an export feature that is supposed to export the data to HTML and CSV forms but it refuses to complete for me.

The second metrics plug-in I tested was much better. It had failed to work the first time I used it because it was not able to access the data that it had collected from the analysis. However, after upgrading to the latest version of Eclipse 3.3 (Version: 3.3.1 Build id: M20070921-1145) this problem vanished.

Metrics view using the Metrics Eclipse plug-in

So, now we needed a code coverage tool or more specifically one that could analyze the tests that have been written for Photran. This is slightly more tricky. We need code coverage tools that can measure coverage on JUnit plug-in tests (vs the normal JUnit tests). JUnit plug-in tests must launch an instance of Eclipse to successfully execute to completion. So a majority of the test coverage tools mentioned here cannot do a decent job.

For instance, in Photran, if you just ran the normal JUnit tests there are only 125 such tests vs 1566 if you run the JUnit plug-in tests. So the coverage is going to be low for the former execution.

There was only one free tool that I could find that offered support for measuring JUnit plug-in tests: EclEmma. The first time I installed EclEmma it corrupted my entire workspace and I had to restore everything from the repository. I installed EclEmma again today on the latest version of Eclipse 3.3 and I think I know the proper way to invoke it so that it will not corrupt the workspace: always create two different run configurations and never mix them. So, when running the Photran, you should always create 2 configurations — one that EclEmma will run and one that normal Eclipse will execute without coverage. And the workspace should also always be cleaned after running EclEmma.

EclEmma code coverage in action.

I believe that the Eclipse update fixed something to make EclEmma work properly on Mac OS X. Yesterday, there was no clean separation of an EclEmma run-time from a normal run-time. In fact, both of them were always merged in the same dialog. This could be why the workspace was being corrupted since EclEmma's instrumentation was replacing the normal ones.

Bottom line, if you want to a good metrics and code coverage tool, go with the Metrics and EclEmma plug-ins. Of course, if you can afford it, go for a commercial tool like Clover.

One would expect that that given the popularity of Eclipse that there would be an easy way to setup Struts with it. However, this does not seem to be the case. There are various resources on how to use some non-standard Eclipse installation (EasyEclipse, MyEclipse) or some outdated plug-in (StrutsConsole, EasyStruts). But it is really hard to find one on how to use a standard Eclipse installation. The definition of what is a standard Eclipse installation is debatable since there are just so many different combinations of it.

In fact, here is a list:

• Developing Struts with Easy Struts for Eclipse
• First Struts Tutorial using Eclipse, MyEclipse
• How to setup a basic Struts project using Eclipse IDE - this one actually comes pretty close to what I need but it is outdated.

However, in my case, I would like just like to use a simple installation that just enables me to launch my Struts application from within Eclipse. I don't really need any of the more complicated features. If I needed those features, I would be using IntelliJ which has great integration with Struts (and almost everything else that you usually use Java with e.g. Hibernate, Spring, etc) built-in.

Fortunately, I found this thread after some searching. The instructions are a bit terse but you can definitely follow along with some trial and error. Just make sure that you have one of the supported servers installed. In my case, I was using the Apache Tomcat server but there are adapters for other servers as well. Also, make sure that you follow (or to be more specific, obey) the folder structure imposed. It's a pretty conventional and there should not be a reason to not put things in their recommended folders.

All that is required is to have the Web Tools Platform (WTP) plug-in installed. My past experience with installing the Web Tools Platform had me downloading a whole bunch of required plug-ins before it could work. Needless to say, it was not a pleasant experience. So I was happy to see that they have released all-in-one package for the WTP project here. This is definitely a time-saver. The WTP is a comprehensive project that is maturing toward the usability and stability that one associates with the Eclipse Java Development Tools (JDT).

Now that everything is working - after much time-wasting - I believe that I have reconfirmed my view that having too many choices is not always good! It's really annoying when all you are trying to do is get some prototype up quickly and you are not able to do that because you have to make a decision between product A, B or C. Sure you can go ahead and read the comparisons and user reviews but most of it is not going to make that much sense to you if you have never used similar products before. And the reason you have never used them before is because you are just beginning to create your first prototype!

I find the situation of having too many choices to be really prevalent in the Java world. I am not against having different choices but I know that when I am just beginning to use some new tool, I would really like everything bundled together so that it just works out of the box! I don't want to select product AA only to be told that before I can use product AA I need to install either product A.1 or product A.2! Just give me a working combination that I can quickly use to see if my prototype can even work in the first place!

And don't get me started on the XML configuration files that are necessary before you can begin running that Java application....

One would expect that that given the popularity of Eclipse that there would be an easy way to setup Struts with it. However, this does not seem to be the case. There are various resources on how to use some non-standard Eclipse installation (EasyEclipse, MyEclipse) or some outdated plug-in (StrutsConsole, EasyStruts). But it is really hard to find one on how to use a standard Eclipse installation. The definition of what is a standard Eclipse installation is debatable since there are just so many different combinations of it.

In fact, here is a list:

• Developing Struts with Easy Struts for Eclipse
• First Struts Tutorial using Eclipse, MyEclipse
• How to setup a basic Struts project using Eclipse IDE - this one actually comes pretty close to what I need but it is outdated.

However, in my case, I would like just like to use a simple installation that just enables me to launch my Struts application from within Eclipse. I don't really need any of the more complicated features. If I needed those features, I would be using IntelliJ which has great integration with Struts (and almost everything else that you usually use Java with e.g. Hibernate, Spring, etc) built-in.

Fortunately, I found this thread after some searching. The instructions are a bit terse but you can definitely follow along with some trial and error. Just make sure that you have one of the supported servers installed. In my case, I was using the Apache Tomcat server but there are adapters for other servers as well. Also, make sure that you follow (or to be more specific, obey) the folder structure imposed. It's a pretty conventional and there should not be a reason to not put things in their recommended folders.

All that is required is to have the Web Tools Platform (WTP) plug-in installed. My past experience with installing the Web Tools Platform had me downloading a whole bunch of required plug-ins before it could work. Needless to say, it was not a pleasant experience. So I was happy to see that they have released all-in-one package for the WTP project here. This is definitely a time-saver. The WTP is a comprehensive project that is maturing toward the usability and stability that one associates with the Eclipse Java Development Tools (JDT).

Now that everything is working - after much time-wasting - I believe that I have reconfirmed my view that having too many choices is not always good! It's really annoying when all you are trying to do is get some prototype up quickly and you are not able to do that because you have to make a decision between product A, B or C. Sure you can go ahead and read the comparisons and user reviews but most of it is not going to make that much sense to you if you have never used similar products before. And the reason you have never used them before is because you are just beginning to create your first prototype!

I find the situation of having too many choices to be really prevalent in the Java world. I am not against having different choices but I know that when I am just beginning to use some new tool, I would really like everything bundled together so that it just works out of the box! I don't want to select product AA only to be told that before I can use product AA I need to install either product A.1 or product A.2! Just give me a working combination that I can quickly use to see if my prototype can even work in the first place!

And don't get me started on the XML configuration files that are necessary before you can begin running that Java application....

For the past couple of days I have been creating an application that I think I would use. And maybe some other people might find it useful too (possibly as an example for doing things in RubyCocoa). For the lack of a better name, I decided to call it flickrPreviewR and hopefully I would not be sued.

It all started when Flock released a new version of their browser sometime last week. I downloaded it since I was eager to see what the perpetually-in-beta browser has created this time. This time I was really disappointed. The only reason for my using Flock was its integration with Flickr. I just like to quickly browse photos without having to use Flickr's interface. Unfortunately, this new version of Flock really left a sour taste in my mouth. Its interface is hideous and the newly revamped Flickr integration seems buggy and really slow. What does it need to do that requires that much computation power? It just needs to fetch the damn photos damnit!

Anyway, this provided the motivation and gave me another reason to play with RubyCocoa. The last time I dabbled with RubyCocoa, I created a version of the RaiseMan application from the book Cocoa Programming for Mac OS X with bindings. Since then, RubyCocoa has had additional changes and I was curious whether it is now easier to develop programs for it. My conclusion: nothing much has changed in terms of the cosmetics of language (there are underlying changes for optimizations, etc), but overall there was nothing new to pick up.

For the backend of this application, I relied on rflickr, the Ruby API kit for accessing flickr. I needed to make some slight changes to the code to accommodate some changes in the flicrk API. rflickr source is bunbled as part of the source code. I did want to not rely on it being a gem since I am not sure how RubyCocoa handles gems and I did not want to add a dependency for the gem; so I just bundled it. flickrPreviewR is under the Creative Commons Attributions License. This might violate the rflickr license and if it does, then let me know and I will see what I can do.

You can find the set of images on my flickr account. I do not have a pro account so I cannot create a set for it. You should read the description of each photo if you are planning on using this. As usual, use this at your own risk. I am doing this as a personal application that I would use and as the developer, I am aware of its limitations and I do not push them while using the application.

One very important limitation that I need to stress is the inability for it to update itself.

There is a weird quirk with using threads in RubyCocoa and NSNotifications. I have not figured out how to get the view to refresh once all the images have been downloaded. Right now, there is the VERY cumbersome need to click on ANOTHER favorite or photoset to force a refresh. The best way to see if the photos have finished loading is to view the progress bar at the drawer.

THIS NEEDS TO BE FIXED once I figure out how.

Here are some things that I picked up while doing this:

• Interface Builder is a great tool for quickly laying out the interface. I cannot imagine how I would have done this with some other GUI toolkit. Even with my familiarity with Java, it would taken much longer just to get all the pieces aligned properly.
• CocoaDev is the site for almost all the questions that you can have on how to do things in Cocoa. Without CocoaDev, it would have taken me a longer time to get things done.
• Cocoa Programming for Mac OS X is a decent reference book once you know your way around how certain things in Cocoa work. That still does not make it a good book to start learning Cocoa programming.
• You can save yourself great pains if you make all your classes subclasses of OSX::NSObject explicitly instead of normal Ruby classes. This will save you trouble when you get weird behavior and crashes. Like me, you might want to use normal Ruby classes sometimes because YAML works well with the regular Ruby classes. In that case, make sure that your class is being used as simple data structure with simple functions that do not rely on any of the Cocoa libraries.
• Threading is hard to do with RubyCocoa and there is little reference on what works and what does not.
• Downloading images with Ruby net/http library did not work for me. The image will always end up corrupted. Thus, I had to rely on curl to download the images.
• WebKit is an excellent piece of work. I used it as the primary backend for displaying the images. To intercept the handlers, I made each preview image be a link an imaginary 'flickr://' protocol. I then overwrote webView_decidePolicyForNavigationAction_request_frame_decisionListener to intercept the call and perform the appropriate actions.

For those who are interested, the source code is here. I did not package it as a stand-alone application because I am not sure what you actually need to run this application. You probably need RubyCocoa and the Ruby 1.8.5. So for simplicity, I just provided the project folder for XCode. If you can build it then you can probably run it.

The current version of ANTLRWorks does not support tree grammar debugging directly. However, there is a way to get it to work using remote debugging. The ANTLR FAQ for debugging has some information on setting up remote debugging but it does not show the remaining steps for tree debugging.

	 1 import java.io.*;
	 2 import org.antlr.runtime.*;
	 3 import org.antlr.runtime.tree.*;
	 4 import org.antlr.runtime.debug.*;
	 5 
	 6 /*
	 7 Sample file that shows how to connect to AntlrWorks
	 8 
	 9 Remember to change the following to suit your own project
	10  - XMLGrammarLexer
	11  - XMLGrammarParser
	12  - XMLTree
	13 
	14 */
	15 
	16 public class TreeTest {
	17 
	18   public static void main(String args[]) throws Exception {
	19       CharStream input = new ANTLRFileStream(args[0]);
	20       XMLGrammarLexer lex = new XMLGrammarLexer(input);
	21 
	22       // MODIFY: change document to the root rule 
	23       ParseTreeBuilder builder = new ParseTreeBuilder("document");
	24 
	25       // create a debug socket proxy to ANTLRWorks
	26       // MODIFY: change the name of the grammar file
	27       DebugEventSocketProxy AW = new DebugEventSocketProxy("/Users/vazexqi/Antlr/handGeneratedXMLGrammar/XMLTree.g");
	28       AW.handshake();
	29 
	30       DebugEventHub hub = new DebugEventHub(builder, AW);
	31 
	32       CommonTokenStream tokens = new CommonTokenStream(lex);
	33       XMLGrammarParser parser = new XMLGrammarParser(tokens);
	34       XMLGrammarParser.document_return root = parser.document();
	35 
	36       CommonTreeNodeStream nodes = new CommonTreeNodeStream((Tree)root.tree);
	37       XMLTree walker = new XMLTree(nodes, hub);
	38       try {
	39           // MODIFY: change to the rule that you want to follow
	40           walker.document();
	41       } catch (RecognitionException e) {
	42           e.printStackTrace();
	43       }
	44 
	45   }
	46 }
	

The original file is available from here.

And when you generate the relevant files for your grammar, you must use the - debug option as such:

	
  java org.antlr.Tool XMLGrammar.g
  java org.antlr.Tool -debug XMLTree.g
	

	
  error(10):  internal error: org.antlr.runtime.debug.DebugParser.reportError(DebugParser.java:88): java.net.BindException: Address already in use 
	

Compile the necessary java files and run the program using java TestTree someFile. Then in ANTLRWorks, select Debugger > Debug Remote....

I spent a couple of hours transforming the RaiseMan application from Cocoa Programming for Mac OS X (2nd Edition). In the RubyCocoa examples folder, there is a version of this but it is based on the first edition of the book. My version includes key-value-binding, undo and redo and also alert panels. I also implemented some of the end-of-chapter exercises that I felt were useful. I skipped the part on Localization though.

Rereading the book makes me think of how much I do not like it. There is very little rationale behind each of the examples. Most of the time, the author just says do this or that. And his anecdotes are pretty annoying (I am not sure where he got his stories from). I felt that the book could have been better if the author spent more time explaining why things are done that way instead of listing the API and describing what it does (it's almost identical to the documentation).

Things actually made more sense to me this time around because I was exposed to some design patterns and could see the rationale behind the way of doing things. I am not sure if a beginning programmer would appreciate the way of doings things just from reading this book. I have heard better things about Cocoa Programming but that book is old and has not been updated. I have not read that book yet so I cannot offer my opinions on it.

Anyway, here are somethings I learned from this effort that may be useful to people:

• Before starting, you should read this page on RubyCocoa to get acquainted with the conventions. You can choose to use somemethodwithargument0_withargument1_withargument2(arg0,arg1,arg2) or somemethodwithargument0(arg0, :withargument1, arg1, :withargument2, arg2) . Once you have decided on one, it is best to stick with it.
• Since you cannot drag-and-drop your MyClass.h (we don't have one, we only have MyClass.rb) into Interface Builder to get it to update any new ib_outlets, you need to do this by hand. The easiest way I can think of is to click on the "Classes" tab on the nib file, locate your MyClass and right click to add actions or outlets. That being said, Interface Builder is pretty good for creating user interfaces. The separation between code and user interface is pretty clean and it is not too hard to get things to work the way you want it to.
• For key-value-binding to work on an array, use kvc_array_accessor. For an example, look at my MyDocument.rb file. More information on key-value-bindings can be found in oc_import.rb in the RubyCocoa source.
• Always, always, always, build and run regularly. There is virtually no good debugging support for RubyCocoa. Sometimes the error message can tell you which file (and in the optimistic case, which line the error occurred at). But in general, it is going to be cryptic. By testing early and frequently, you can at least narrow the error down to the last edit that you made.
• Remember to qualify your ib_outlets when you used them with the '@' symbol. For instance, if you have ib_outlet :some_object then in your methods, you refer to that object as @some_object. I am not sure why I keep forgetting this but it has been the cause of many problems.
• Remember to always prefix Cocoa classes with OSX::. You can avoid this by using include OSX. Also be careful that you check the spelling for the Cocoa classes (you need the NS prefix, etc). Misspellings have bitten me quite a few times.
• Read oc_attachment.rb in the RubyCocoa source code to find out how you can use Ruby idioms like [], []=, etc for accessing arrays and dictionaries. Also decide if you want to use those notations or just stick with objectForKey(), etc.
• There are some idiosyncrasies with OSX::NSRunAlertPanel. You cannot do Ruby string substitution in the arguments. If you need string substitution, you can do it using the special @ symbol as such: choice = OSX::NSRunAlertPanel("Delete", "Do you want to delete %@ records?","Delete","Cancel",nil, selected.size).
  

One problem that I had was that I was not able to build it for release. I had to build it for debug. I think there could be something wrong with the way the project is setup. Anyway, the file is available from here.

Update: I just installed RubyCocoa 0.9 from Subversion. Instructions can be found here. I can now successfully built it as a universal binary. The next test I did was to run this RaiseManager application. I was greeted by a successful build... but the application could not create new employees. The error logs report that there is something wrong with the NSUndoManager but I suspect that it has something to do with key-bindings since there is supposed to be some change to how that is done in RubyCocoa 0.9. I will have to take a look at that. On the bright side, RubyCocoa is approaching the 1.0 mark after so many years!

Update (Jan 3, 2007): The latest version from the Subversion repository has addressed the issues that I reported above. The current working version (revision 1325) was checked in today by Laurent. Suffice to say that there are major additions from RubyCocoa 0.5 that are worth checking out. It would be good to see how RubyCocoa plays with the new Objective-C 2.0 that is included with Leopard. On a side-note, there is a new Ruby/Objective-C bridge out by Tim Burks here.

Lots of Java frameworks rely on configuration files to function. These configuration files are usually written in XML (which I still strongly believe is not human writable). Whilst the IDE usually provides nice auto-completion features for these configuration files, it is not able to reflect refactoring changes made to the Java source files. For instance, if the XML file refers to com.vazexqi.sample.Class and I rename it to com.vazexqi.sample.Class2, the XML file is not updated. I wish to study the feasibility of adding refactoring awareness for these configuration files in the Eclipse IDE. For starters, I will try to hack around with the Hibernate Tools plugin.

In case anyone is interested in following along, here are some of the steps that I have taken to get started.

Getting Hibernate Tools

I use the Help > Find and Install... feature in Eclipse to install Hibernate Tools. The site URL for Hibernate Tools is http://download.jboss.org/jbosside/updates/development/. There is nothing there for your web browser to load; it contains a site.xml for Eclipse to discover new features. Over the past few days I have had some trouble accessing the site so be patient if you cannot reach it as well. There are three major dependencies that Hibernate Tools has: Visual Editor, Eclipse Modeling Framework and Web Tools Platform (WTP). When you first try to install Hibernate Tools, it will warn you of those dependencies. So you will need to go grab the relevant plugins first. The three of them are listed under Callisto Discovery Site. After installing Hibernate Tools, it is a good idea to find out what features its XML editor provides. I followed the tutorial on the Hibernate website.

There is no need to grab JBoss Eclipse IDE, just Hibernate Tools will do.

The XML editor is based on the one from the WPT plug-in. The original WTP XML editor supports completion based on the XML schema (either DTD or XSD; I don't think it supports RELAX NG). Hibernate Tool extends it so that it supports completion for Java class names for the relevant attributes in a XML tag. Completion is suggested via the normal key sequence: CTRL + space.

I played around with Hibernate to discover what features the XML editor supports. This will help me when I need to hack it into submission.

Getting Hibernate Tool source code

To ensure that the version of Hibernate Tools you installed does not interfere with the source code when testing, you should disable it. The easiest way to do so, is to go to Help > Manage Configuration and select Hibernate Tools from the list on the left hand side of the screen. Click disable. You should be prompted to restart Eclipse. When you restart Eclipse, it will no longer load Hibernate Tools. If you need to load it again, you can always follow the steps again but this time select "enable" for Hibernate Tools. You need to select the third icon from on the toolbar to see the disabled plugins.

To start hacking away you need to get the source code from the JBoss CVS repository. There are some instructions here.

I used a slightly different route. I switched to the CVS Repository Exploring view and browsed the CVS repository at anoncvs.forge.jboss.com:/cvsroot/jboss. I then selected the following packages (individually) from HEAD/jbosside:

• org.jboss.ide.eclipse.freemarker.feature
• org.hibernate.eclipse.updatesite
• org.hibernate.eclipse.test.feature
• org.hibernate.eclipse.releng
• org.hibernate.eclipse.feature
• org.jboss.ide.eclipse.freemarker
• org.hibernate.eclipse.mapper
• org.hibernate.eclipse.jdt.ui
• org.hibernate.eclipse.jdt.apt.ui
• org.hibernate.eclipse.help
• org.hibernate.eclipse.console.test
• org.hibernate.eclipse.console
• org.hibernate.eclipse

The freemaker packages are not really required but without it I get some configuration errors when I run Hibernate Tools and try to manage it with Help > Manage Configurations.

At this stage, you should be able to run the packages above as a single Eclipse application. Make sure that the WPT plug-ins are enabled since there is a dependency for it.

Over the next few days I will be looking at the source code and seeing how Hibernate Tools offer completion for Java class names. From here I will try to find out how the information is embedded (it cannot be in the DTD or XML schema since that form has to remain compatible with other applications that use it). Next, I will try to register the plugin to receive notifications whenever a refactoring (rename, move, pull-up, etc) has been done and modify the referenced Java classes in the XML file.

Hopefully after this I will get a better idea on how to develop a general framework that will allow support for different types of configuration files.