This sort of thing makes me so mad I could spit

Often projects have external dependencies. Sometimes their whole job is to resolve external dependencies. Maven, yum, rubygems, heck CPAN!

These projects should be built as if their dependencies are trying to deliberately sabotage them. Reminds me of the talk I saw at Uberconf that drove home that point: stuff goes wrong, so you gotta protect yourself at all of the integration points.

When it comes to external dependencies, if something goes wrong, you really need to point the user in the right direction. You need to say “here’s what I was looking for, and here’s why I was looking for it, and here’s where I looked, and here’s what I got, and here’s what’s in my cache, and here’s the problem, and here’s what you can do once you’ve figured out why I got the wrong answer.” Then the user has some idea what to pursue. When they get an error like “Could not resolve dependency xyz” then guess where they end up? Posting desperately on some forum somewhere. Or Googling for that forum post.

Which brings me to today’s offender: Eclipse. Oh, Eclipse. Despite copious (even overwhelming) feedback to the user, how rarely you succeed in producing useful diagnostics. It’s bad enough when you’re installing a plugin and one of the dependencies in some repo is missing. Then you at least have a fighting chance of realizing that it was a dependency and who might be to blame. But Eclipse also validates XML against the stated DTD, and guess what? That’s an external dependency. And guess what happens when something goes wrong with that dependency?

Evidently Eclipse caches the broken DTD and refers to that to declare your XML invalid with the useful error message: Referenced file contains errors ( For more information, right click on the message in the Problems View and select "Show Details..."

Now that I look at the error, it’s actually better than I first read. It does blame the DTD, and it does say where it got it. At first I read this more like “Your file has errors.” (Helpful! Also what someone would see if they didn’t know what a DTD was for.) OK. Once I downloaded that file myself, I could see that it was broken. Actually seems to be sporadically serving that file wrong.The second time I downloaded it, it was fine. That’s going to happen, though, see? That’s sabotage. The really broken part here was that Eclipse actually cached that broken DTD after downloading it. You’d think that having detected it was broken, it might retry the download each time a validation was needed. It might provide you a mechanism to request a new download. It might actually inform you that the file is cached, for those of us not familiar with Eclipse internals.

A helpful error message would have been something like: “Eclipse tried to validate this XML file’s schema with the DTD downloaded from (as specified in the file) and cached at the location /some/path/urlrewrite3.0.dtd. This DTD file has errors; please check the DTD URL specified and the cached file to determine the source of the errors. To clear the cache and try the same URL again, (follow these instructions).”