Maven Install does not Package

This episode started with our use of Jenkins. But ultimately it had to do with how Maven was behaving with regards to the various lifecycle phases. Our original command was "mvn clean install". 

This would be the norm for most of our projects, except for one module which was generating stub files from the WSDL of another. One particular object - let's just call it com.blogger.quirksofit.vehicles.QuirkyParentType - is being extended by numerous others in a com.blogger.quirksofit.vehicles.cars subpackage. Class QuirkyParentType will always be generated into com.blogger.quirksofit.vehicles, but depending on how the project JAR was being built, QuirkyParentType may or may not be generated into com.blogger.quirksofit.vehicles.cars where the subclasses reside.

This problem doesn't surface until our tests where the first module calls the other. The backend replies with an ambiguous XML tag for QuirkyParentType which the front determines to be part of the com.blogger.quirksofit.vehicles.cars subpackage. And if the Maven build was not done correctly, this will all break.

We noticed that "mvn clean install package" helped, to a certain extent. The source file for QuirkyParentType was generated, but it was still not propagated into the Maven repository. What did manage to do the trick, was when we tried to call "mvn clean package install" out of exasperation. We'd previously assumed that the Install phase should call Package first. This did not happen for some reason. And by putting package after install, the repository was updated before the source was generated.

Finally, we put all of this into Jenkins to complete the build and left for home, and our late night dinners.

Quartz Scheduler needs synchronised clocks in clustered environment

We had batch jobs that we refusing to work and were misbehaving with erratic schedules that were rarely successful. The tasks were making use of Quartz which were sitting in a cluster of servers. We didn't think much of it that one of the servers were misconfigured with a different timezone previously as this was in a development setup. This errant server was 8 hours behind, using UTC as its timezone.

A few attempts later, I managed to convince the machine to adopt our timezone instead. But the application server still refuses to follow suit. Fortunately, I found out how to change its timezone as well, after a few false starts.

The jobs then came back to life after they snapped out of their jetlag. The difference in timezone was causing a lot of misfirings to occur as each cluster node checked in on each other via the database.