Running Nightly Builds as XP Scheduled Task - Classpath Issue

Question

I'm running JUnit nightly builds on my computer as a scheduled task in Windows XP. My application uses Jaxb, therefore some of the tests need to reference xsd schemas using the system classpath. When the nightly build runs while I'm not on the computer, I get an error like this:

java.lang.Exception: Unable to load schema mySchema.xsd from classpath

However, when I run the build manually I get no such error. The environment variable for the location of my schemas is a System variable, not a User variable, so I don't know what could be causing this error. What could be cause of this error?

EDIT: Alternatives like Hudson is not what I'm asking for. I'm asking for a solution for the technology described above (batch file running as a scheduled task).

Answer 1

You should check out Hudson or Cruise Control. Both are easy to setup and will take care of this type of problem for you with more reporting, control, and improved usability. You'll spend less time investigating build problems.

Answer 2

My suspicion is that your working directory is different from what you expect (rather than the classpath variable specifically). It's not immediately obvious if you are running this scheduled task as a user or as a system task. In either case, it's worth finding out exactly where the task is running.

That said, while I used to set up automatic builds using Windows XP scheduled tasks (exactly as you are doing now), we currently use CruiseControl. In the abstract, this isn't that much different from what you're doing (running a build regularly) but it increases your flexibility. Around here, the most valuable ability of CruiseControl is to detect that changes were committed and to only run the build then. We find out about broken builds, broken unit tests, etc., within 10 minutes of a commit now.

Answer 3

hudson is another continuous integration engine, that is very very simple to setup:

Hudson offers the following features:

• Easy installation: Just java -jar hudson.war, or deploy it in a servlet container. No additional install, no database.
• Easy configuration: Hudson can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help. There's no need to tweak XML manually anymore, although if you'd like to do so, you can do that, too.
• Change set support: Hudson can generate a list of changes made into the build from CVS/Subversion/Mercurial. This is also done in a fairly efficient fashion, to reduce the load of the repository.
• Permanent links: Hudson gives you clean readable URLs for most of its pages, including some permalinks link "latest build"/"latest successful build", so that they can be easily linked from elsewhere.
• RSS/E-mail/IM Integration: Monitor build results by RSS or e-mail to get real-time notifications on failures.
• After-the-fact tagging: Builds can be tagged long after builds are completed JUnit/TestNG test reporting: JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc. History trend is plotted into a graph.
• Distributed builds: Hudson can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers' desks. File fingerprinting: Hudson can keep track of which build produced which jars, and which build is using which version of jars, and so on. This works even for jars that are produced outside Hudson, and is ideal for projects to track dependency.
• Plugin Support: Hudson can be extended via 3rd party plugins. You can write plugins to make Hudson support tools/processes that your team uses.