title: Dependencies inside war-package vs. shared libraries
body: <p>Typically, dependencies are bundled inside Java .war-packages.</p>
  
  <p>However, one could also drop the dependencies into shared libraries, to use the same dependencies for each of the deployed artifacts.</p>
  
  <p><strong>The question:</strong> what are the benefits and drawbacks of each approach? In which situations would you use them?</p>
  
  <p>The biggest requirement is intuitiveness/maintainability. I don't care too much about memory consumption, disk space usage, bandwith, etc. as those are cheap to buy.</p>
  
  <p>Anyway, some points for each:</p>
  
  <p>Including dependencies inside WAR:</p>
  
  <ul>
  <li>"De facto" approach(?)</li>
  <li>Easy to maintain (needs less configuration &amp; scripting, etc.)</li>
  <li>Easy to deploy to app server</li>
  <li>Each module can define specific versions on libraries</li>
  <li>Reduces risk for classloading errors?</li>
  </ul>
  
  <p>Using shared libraries:</p>
  
  <ul>
  <li>Reduced memory consumption (trivial?)</li>
  <li>WAR deployments can access the same instances/variables etc. as they share the classpath? It actually sounds really bad? (does it really work that way, or are they run in separate contexts, just using the same physical files?)</li>
  <li>Makes doing distributions and deployments more difficult as dependencies have to be separately maintained/deployed</li>
  <li>Packages are smaller in size (trivial)</li>
  <li>Dependencies can up upgraded without actual re-deployment of WAR apps (what's the benefit, really..)</li>
  </ul>
  
  <p>Of course, we could use the best aspects of both approaches and just provide the common libraries as a shared lib, and include version specialities inside WARs. However, this doubles the maintenance effort and feels like a no-no.</p>
  
  <p>Currently I'm using Glassfish 3.1.1, but this question is really app server agnostic.</p>