Today, I set out to create an Eclipse update site to host Team 449’s plug-ins. (If you’re in a rush for answers, just scroll to the bottom.)

Eclipse is actually one of the less buggy of applications. It doesn’t crash every three minutes like Bloodshed Dev-C++, it doesn’t crash every two minutes like Internet Explorer, and it doesn’t crash every minute like Windows. The Java development environment is beautiful, the task management system is well-designed if poorly-integrated, and the C++ development environment is second only to Emacs, Vim, Ed, and the ever-elusive butterfly technique (its not actually that great). Eclipse has a unique system of managing views and perspectives that allows a huge amount of flexibility to the user. But Eclipse’s plug-in development environment is less than satisfactory to the developer.

To begin with, Eclipse plug-ins are based on a less-than-easy-to-use API. Sure, its easy to do the things the designers anticipated you would be doing – like compiling their sample projects. But there’s no level of abstraction between “here’s a method to do exactly what you want” and rewriting half the API from scratch. Furthermore, the Eclipse developers insisted on creating their own system for everything, from user interface functionality to file system access. A good deal of the documentation is totally obscure, and the sample projects are no help.

Now suppose you’ve suffered through the experience of writing a plug-in, you’re almost done, and you’re ready to export. Or more likely, you’ve just begun, and you’re ready to export just to see what happens. There’s just one little problem – that tiny icon over in the “package explorer” with the red X or the yellow exclamation point – Eclipse doesn’t like something. Such was my situation as I was trying to export my plugin, so that I could export my feature, so that I could test my update site.

Now if you’re lucky – and odds are you’re not – that little icon will be over a “.java” file. That means you messed up your Java code, and that can be fixed with relative ease. If you’re unlucky, that icon will be over the build.properties or MANIFEST.MF file. You double click on that file, glance through the tabs, and discover that in none of the tabs does Eclipse have a complaint.

So I think to myself (or you think to yourself), “oh, I’ve been here before. I just have to look really carefully, and I’ll find it.” Now, I think that memory is actually a dream. The technique didn’t work. Ok, maybe Eclipse is caching something. Nope, restarting Eclipse doesn’t help.

The end result was that I went to the tab ”plugin.xml”, went through the source code, found the error, went to the related part of the wizard, and fixed it. But that’s not what happened next.

I decided that the warning probably didn’t matter, so I went right ahead and created my update side. Oops! It won’t let me add plug-ins, I can only add features. Ok, that’s fine, I’ll create a feature with one plug-in in it, and add it. I create the feature – no problems there. I add it to the update site – no problems there. I click ‘build all’, thinking, “wow, this is easy!”

Nothing happens.

I remove the feature and put it back in. Doesn’t help. I create a category and put the feature in it. Doesn’t help. Finally, I decide to go back and fix the plug-in. I finally land upon the correct tab, find the problem, find the associated part of the wizard, and fix it. I go back to the update site, remove the plug-in, add the plugin, and click ‘build all’. The progress bar scrolls nicely along, and then I refresh the project. Tada! Lots of new material. I look through it and like what I see. Now I’m ready to place this site online.

I create a new directory in my raw data folder (created as an easy way to avoid ending up with my serving script happily spitting out its own source code, passwords and all) called “eclipse-update” and copy the whole mess produced by Eclipse into there. The content.xml file is surprisingly large, but at this point I don’t have enough curiosity to find out what’s in it. Now, as a test, I go there in my web browser. Here, that is. And what I get is:

Eclipse Update Site Not Working

In case you can’t make it out, it says “undefined”. I look at the source code, and it is just one big mess of Javascript.

So again, I try to just accomplish the goal, and leave all the niceties to rot. For once, things decide to start working. I add the update site, and everything shows up properly. I select “Team 449 Eclipse Plugins” and click ‘install’. The progress bar moves, albeit somewhat sluggishly, my Internet connection falters but does not die, and the selected items install. Well, sort of. There was just the little glitch of, Eclipse appeared to think that every plugin I had installed on my machine was a dependency for the one I had created, so I made a mental note to fix that. Other than that, there was no problem installing.

Now its back to fixing the niceties. With my fingers crossed, I go to the index.html page again, and check firefox’s error console for errors it produced. If there were any, fixing them should be easy. Nope, none (save for some CSS errors). Great. Now I go to the source code. Here it is (without the HTML):

  1.  var returnval = 0;
  2.  var stylesheet, xmlFile, cache, doc;
  3.  function init(){
  4.   // NSCP 7.1+ / Mozilla 1.4.1+ / Safari
  5.   // Use the standard DOM Level 2 technique, if it is supported
  6.   if (document.implementation && document.implementation.createDocument) {
  7.    xmlFile = document.implementation.createDocument("", "", null);
  8.    stylesheet = document.implementation.createDocument("", "", null);
  9.    if (xmlFile.load){
  10.     xmlFile.load("site.xml");
  11.     stylesheet.load("web/site.xsl");
  12.    } else {
  13.     alert("Document could not be loaded by browser.");
  14.    }
  15.    xmlFile.addEventListener("load", transform, false);
  16.    stylesheet.addEventListener("load", transform, false);
  17.   }
  18.   //IE 6.0+ solution
  19.   else if (window.ActiveXObject) {
  20.    xmlFile = new ActiveXObject("msxml2.DOMDocument.3.0");
  21.    xmlFile.async = false;
  22.    xmlFile.load("site.xml");
  23.    stylesheet = new ActiveXObject("msxml2.FreeThreadedDOMDocument.3.0");
  24.    stylesheet.async = false;
  25.    stylesheet.load("web/site.xsl");
  26.    cache = new ActiveXObject("msxml2.XSLTemplate.3.0");
  27.    cache.stylesheet = stylesheet;
  28.    transformData();
  29.   }
  30.  }
  31.  // separate transformation function for IE 6.0+
  32.  function transformData(){
  33.   var processor = cache.createProcessor();
  34.   processor.input = xmlFile;
  35.   processor.transform();
  36.   data.innerHTML = processor.output;
  37.  }
  38.  // separate transformation function for NSCP 7.1+ and Mozilla 1.4.1+
  39.  function transform(){
  40.   returnval+=1;
  41.   if (returnval==2){
  42.    var processor = new XSLTProcessor();
  43.    processor.importStylesheet(stylesheet);
  44.    doc = processor.transformToDocument(xmlFile);
  45.    document.getElementById("data").innerHTML = doc.documentElement.innerHTML;
  46.   }
  47.  }

Ahh…. This makes some sense. First, I note that IE is treated differently. Does the IE version work? Yes! Now we can ignore all the non-IE parts. I pull up Safari 4 Beta and test it there. It doesn’t work there instead: I get the popup error message “document could not be loaded by browser”.

This is an important clue, since I know that this error message is only supposed to pop up when xmlFile.load, which is a function, does not exist. On the assumption that xmlFile is a document, I search and discover that even the examples on W3Schools don’t work on Safari. Great – the one browser that passes Acid3 doesn’t even support “standard DOM Level 2 techniques”.

This just leaves Firefox. Suspecting that the problem lies in transform(), I add alert() statements for each variable. My discovery is that everything exists but doc.documentElement.innerHTML. After experimenting around a while, I decide that it is probably the fault of Firefox. Just to be sure, I navigate to some other update sites. I get a variety of results, including raw xml, but none of them actually work.

The Answer

Be sure there are no warnings in any build.properties files by going to the tab that contains the xml code, finding the error, and correcting it by finding the related part of the other pages. Then remove from and place back in the update site the affected plug-ins. Build your update site, and then refresh the project so that you can see what’s going on.

You can just use an ftp client to upload the files now, and your update site will be working. Be sure to copy all of the files to your host server. Your update site html page will not work in many browsers, so you should write your own.

Related posts: