Our project currently exists in two related packages. The RememberOneAnother project (I will call it ROA for brevity) depends on what we decided to call ‘foundation’. We are using Hudson, the continuous integration engine, for automatic deployment of our code. Hudson is deployed on our Apache-Tomcat server, which is deployed, in turn, on our web server, and configured to check our Subversion repository hourly for any modifications to our webapp. If these are detected, Hudson’s marching orders are to auto-run ‘mvn package’ and a shell script to move the packaged webapp into tomcat’s deployment directory. By this means, we don’t have to do anything more than commit changes to the subversion repository, and they will appear on the web.
Unfortunately, this was, until today, only true of builds independent of each other. A change in jsf-util would not trigger a build in ROA, which could result in the app not feeling the affect of an update for days. So, we investigated build triggers with maven and Hudson.
Mr. Chandler discovered a how-to in the maven docs.. To summarize, it instructed us to add tags to our pom.xml files for each project and create a parent pom.xml in the directory above them. Running ‘mvn clean install’ from that parent directory would cause both projects to compile.
Hudson supports multi-build triggers, so this may not have been the only way to solve the problem. Even if there was another way, however, Hudson seemed quite friendly towards our method.
It was slow going getting the poms edited and the system re-compiling. We did a good deal of refactoring and moving of files, and eventually there was some confusion about which copies we were editing. It ended up taking most of the day, but we got the refactoring done and finally committed all three new poms to our subversion repository.
Hudson did not build ROA successfully, so we took the easy way out and created a new job under the parent directory, so that Hudson repeated the ‘mvn clean install’ process we had been using offline to test our work. After we allowed Hudson some more memory, he put our application online with a single click of a button on our part. It was rough going today, but will hopefully save us a lot of time in the future.
Moving beyond the coding to anecdotes, hardly a day goes by when I do not suddenly recall editing a certain file, moving a certain file, or, (in the worst cases) deleting a certain file, in such a manner that we worked for quite some period to fix a bug that “just shouldn’t be happening.” When I recall, I groan slowly, and embarrassedly try to explain why it had been a good change to make at the time, but not a good one to forget about later. These are some of the most tragically humorous moments of the day, and I intend to recount them as daily “Notes for Dense Summer Interns.”
This time around, it was a file I had copied off to a different directory — while accessible to Eclipse from one directory, I needed it in an empty folder to allow Subversion access to it. This, unfortunately, led to our editing of the wrong file, and some serious head-scratching when the revisions didn’t have any effect.
The number of the day is 96, the number of lines of stack-trace my code generated a few days ago.
Filed under: Jobber's Log | Tagged: Hudson, Maven, Subversion, Tomcat
