I would discourage you from persuing a patch build solution. I would suggest that a patch build be treated as an entire new build. There are several advantages to this approach.
1. The build and deployment process is always the same. 2. The person doing the build and deploy does not need to know what has changed, and therefore will not need to do anything differently in order to deploy the build. 3. The build will move through your environments as a single unit. This will ensure that the changes are tested and deployed together with their dependecies, etc. -Rob A > -----Original Message----- > From: S I [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 12, 2005 9:19 AM > To: [email protected] > Subject: Doing patch builds > > > Hi > > I was hoping someone could put me on the right track please. > > I finally automated my whole build and deployment as well as > writing code to > handle branch builds. Now I need to write code to handle > patch builds. > This is when the developers hand over couple of modified > files which need to > be compiled, packaged, and delivered to our production to be > deployed (in a > .war file) to the live site. > > I'm not sure how to go about doing a build that looks into > CVS for the > changed files, compares them to a list sent by the > developers, and then it > parses out their corresponding .class & .jar files or > deliverables and > packages them into a .war file? This brings me to my next > question: Does > anyone know if Tomcat needs the complete war file to explode > or could it > just explode a war file which contains only the latest > modified files and > replace the files on the live site? Any ideas? > > Thank you > > Steven > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
