This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
Hi all, We seem to have an ongoing debate here regarding WAR file deployment and whether to include dependent libraries as part of the WAR file or not. I have done the reading and understand why you might put JAR files with libraries shared by multiple applications in some shared lib folder, but I am of the opinion that this should be done sparingly. Here, the development team does not deploy code into production (or even to test). So it is my goal to make the steps to deployment as simple as possible for the testers and the production sys admins, both of whom just go by what instructions we give them, and are ill equipped to solve JAR file dependency or conflict problems. I say moving one WAR file with everything the application needs is much easier and has far less room for error than moving several files into multiple locations. In addition, it makes a new developer's life easier when trying to get the application up and running on his machine. Others here take issue with this practice, claiming we should putting in the WAR file what is absolutely needed, with the bulk of the JAR files in a shared lib folder. Their main gripe seems to be the larger WAR file we end up with when including all libraries. I can't get anyone to tell me just what problem this causes (there's 80GB of disk space sitting there), and to me it solves potential mistakes made by those deploying the application. So I am seeking input from my JavaRach friends. What rules of thumb do you follow in your environments? Any thoughts appreciated.
Both on-the-job and in my own personal development, I keep the common jars in the common folders and only put jars unique to a single web app in the WEB-INF/lib folder of the app (and hence into the war file). That's the way things are going to be in the production environment, and so I like to make sure that the development/test environment matches the production environment as much as possible. That said, if such a setup created un undue amount of wasted time chasing silly classpath problems (I've personally had no such manifestations), I'd have no problem doing it differently. bear