Hi, Here's the situation, then.
The iReport tool (and hence JasperReports) bundles scores of JAR files across two different directories. (One of these JAR files conflicts with a JAR file deployed by Tomcat.) For development purposes it makes sense to have Tomcat and iReport installed on the same machine. This poses a maintenance issue in the following scenarios: 1. *Bundle JARs with Servlet.* When deploying a JSP or Servlet that uses JasperReports, make a build script that packages up all the required JAR files into a WAR file before deploying to Tomcat. 2. *Common libraries.* Copy the JAR files into Tomcat's common library directory. In the first case, multiple applications using JasperReports will result in a gross waste of resources as each WAR file would have to contain the entirety of JasperReports. Although this allows for different applications to use different versions of JasperReports, I believe that to be an uncommon scenario. It is possible to write and maintain multiple build scripts that use a single location of JasperReports as the source of JAR files. This is a hassle and still does not resolve the problem of having to bundle JasperReports multiple times. In the second case, there seems like there is nowhere to put the JAR files that would not mix with existing JAR files. I am looking for a spot to place all the JasperReports JAR files such that: - Upgrades are trivial (erase a directory, copy new version, done) - All applications can use it (one version of JasperReports for all applications) - The JAR files do not mix with other files - Maven, Ivy, or Ant is not required to maintain the JARs Further, this leaves two copies of the JAR files on the development machine: one in Tomcat's directory and one in iReport's directory. I'd prefer a way to only use a single copy: the one with iReport. That way, when iReport is upgraded, Tomcat need only be restarted. Any ideas how the maintenance burden of multiple copies of JasperReport's significant number of JAR files can be eliminated (without using the "evil" CLASSPATH)? That's because the CLASSPATH environment variable is inherently evil. Don't > ever use it (goes double for Tomcat). Anything recommending setting > CLASSPATH is immediately suspect and not to be trusted. > Then why call the scripts "setclasspath" when you don't actually set the classpath? ;-) Thank you! Dave
