I am trying to automate the build and deployment process in my project. Currently build.xml generates the war file and I have updated the script to copy the war file to the required destination in the linux environment. But before transferring the war file to the linux server, I need to explode the war file and edit few of the configuration files and pack them back to the war file. Hence request you all to help me or guide to update my ant script (build.xml) to achieve my above requirement.
The problem is, the generated war file is of from the default entries, which I am not supposed to edit it before the generation of the war file. I am supposed to edit the war file after the successful build.
Joined: Mar 22, 2005
I would question that, as it doesn't seem to make sense. But regardless, a war file is just a zip file with a different extension, so you can use the unzip/unwar task to extract its contents, edit them to your heart's content, and finally war them back together.
The following steps for edit and update the war file content in linux
1. Just right click your war file.
2. Select 'open archive manager'
3. Then which file you want to edit, just open that file and edit the content.
4. Then system ask to update or cancel, when you close that archive manager dialog box.
I hope , its useful for u.
Wake up! Don't let your smile be snatched away by anybody!
Joined: Apr 20, 2009
Thanks a lot for your reply. Could you please help me out to carry out the above steps through the ant build script!! I need to automate the build process. Hence I need to update my build.xml file to accomplish the above tasks specified by you.
Joined: Mar 22, 2005
After having read the documentation of the unwar/unzip Ant tasks, what, specifically, is unclear about how to do this?
Actually, I design all my webapps so that you don't have to edit the war file. The exact same byte-for-byte copy of the WAR serves for local testing, Beta testing, and production. I do this by defining the variable parts of the webapp as externally-injectable resources that can be retrieved via JNDI. The database location info comes that way naturally, since I always use server-pooled DataSources, but I also use external resource definitions to specify where file upload directories are, locations of server-specific property files, and so forth.
It makes the program design slightly more complex, but keeps the build simple. Just as importantly, it ensures that the wrong copy of a WAR doesn't get deployed and have Production updating a Test database or vice versa. Since there's only one copy, it's never the "wrong" one.
Customer surveys are for companies who didn't pay proper attention to begin with.