The optimal result would be having one war file that will work on both Tomcat 5 and Tomcat 7 and is the same for every customer.
You can use maven profiles to adopt the build for every customer but I recommend to externalize the individual config into JNDI or an external properties file read via some environment variable. Spring offers the PropertyResolverconfigurer to do that (for example)
Since you want to support Tomcat 5 I guess your project builds with Java 1.5?
That should run on Tomcat 7 as well.
The javax dependencies should have scope provided in your pom.xml files. So they will not be deployed. If your application requires a specific version of a jar that is part of tomcat already you may be able to solve that with profiles as well. But this may conflict with per-customer profiles.
If there a big differences between your Tomcat 5 and Tomcat 7 version it may be an idea to create 3 modules - all using packaging "war". One containing the 'neutral' files, one containing the tomcat 5 files and one the tomcat 7 files. The tomcat projects would use the neutral module as war file dependency and maven will do a war overlay. So one build would produce both tomcat 5 and tomcat 7 version (and a neutral war file that is not used for deployment).
according to http://tomcat.apache.org/whichversion.html the minimum java version from tomcat 5 is java 1.4. But that relates to what the tomcat is running on. A tomcat 7 should be able to run Java 1.5 bytecode as well. Just its JDK is 1.6. You could use 1.5 for the source and target version of the maven-compiler-plugin to target both version.
But I think it should be possible to create a tomcat 5 build that will run on tomcat 7 as well. Do you have any dependencies that conflict between the two versions? or do you pre-compile the jsp files?
For the maven build you will need just one jdk (1.6) to be able to compile sources for an older target version too.