Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Hudson's build facility is somewhat simple. You tell it where to grab the source and then it will build. Each build will checkout what you tell it to and begin building from the directory you specify. This only presents a few minor problems. My first thought was to check out the entire source tree and then dive into each individual directory (maven, struts1, struts2, sandbox) and launch a build. This did not work since Hudson wants to do one build at a time. Also, it does not allow you (as far as I could tell) to specify the same workspace for subsequent builds. Fortunately, this was relatively easy to work around. The Struts 1. x and Struts 2.x builds depend on the struts-master and struts-annotations artifacts. Although these artifacts are published to the public Maven repositories, they contain information that the other builds need. For instance, the top-level pom.xml in the struts2 source directory declares struts-master as it's parent. To make this work, I setup struts-master and struts-annotations as their own builds in Hudson. The build setup for these two simply points to their source directory in SVN and runs the clean and install maven goals. This way, both artifacts are installed into the local maven repository for Hudson. After that, I setup builds for both the struts1 and struts2 directories in SVN.

Build Setup - Struts 1.x

The Struts 1.x build is done the same way that a person would do it. Hudson is directed to check for changes in SVN, if the source has changed since the last build, launch a new build. Let's take a look at the current setup -

Image Added

Currently, the build is not setup to throw away previous builds or enable parameters.

Code Block
xml
xml
<action name="SomeAction" class="com.examples.SomeAction">
   <interceptor-ref name="@INTERCEPTOR-REF-NAME@"/>
   <result name="success" type="freemarker">good_result.ftl</result>
</action>