>This has been floating around for a while in my head so it’s time to shake it out. Considering I’ve been breaking the XSL Tools build recently, but everything runs fine locally, I’d thought I’d share the common failure points and why:
- Can’t locate Plugin – build crashes after 2 minutes during feature dependency checking. The cause in this case was a dependency range issue. The version of the plugins the build system had from its target platform were not exactly what I had in my system. Solution in this case was to loosen the plugin dependency range to remove the maintenance release version number. Which I didn’t happen to need. Alternate Solution: Update the target platform the build system has (not an option in my case with out involving another person to update it).
- Can’t locate Plugin – Yes this one again, but caused by a different issue. In this case it was caused by a MAP file not being updated correctly to contain the new plugins that were needed for the unit tests. Something that running and executing from within the IDE is not going to catch.
- Unit Tests fail with NullPointer Exception – this was caused due to the way unit tests have to be unpacked in order to access files and directories in the jar. Note: If using Athena Common Builder this should not be an issue as Nick has this working with Athena.
- Missing Directory or Can’t locate file – caused by the build.properties file not being updated to include the appropriate directory in the jarred plugin.
- Can’t locate Plugin – Yep again, however, this time caused by plugin.properties not being included in the build.properties file correctly. The feature build couldn’t locate the plugin name or id.
Other items I’ve seen that cause build failures include:
- Missing target platform dependencies from either not retrieving from orbit, or not deploying your upstream dependencies to the build machine. In these cases, the provisioning for the build may need to be updated. You may have to update Hudson or CruiseControl if checking code out from head, or you may need to update a build.properties file correctly if using Athena Common Builder.
- Incorrect Tagging of Map files – If you don’t tag your map files and release correctly, you can get all sorts of errors that are difficult to track down. It’s one of the reasons I prefer to build directly from head instead of MAP files. If using Hudson, you can always TAG a build after it is done, to lock the file versions that were used to build in place. Also, if you need build promotion, you can use the Hudson Build Promotion plugin to promote a build.
- Failure to Continuously Integrate with Head – A common issue that can occur is that your local copy of the files aren’t in synch with what the MAP files have or what is currently in Head. It’s always a good practice to keep your copy synchronized with what is in head to catch integration issues early as possible.
Those are what I have seen, several don’t have to do with Eclipse builds, but builds in general. The five that happened to me recently were because I did not update the appropriate meta data correctly for the automated build. PDE is a bit more lenient when you are running the code from within PDE. Many of these could be caught by exporting the feature or plugins from the build, but some still slip through. All of these errors can be caught by looking at the log files. Hudson’s Console Output is a good way to see what is happening, CruiseControl tends to mangle the log outputs so it’s a bit harder to track down the issues.
So next time you have some build failure issues, hopefully these common causes can help you track down why, and how to fix it.