Support for multiple war files

[RadiatorSpring]

What happened?

• What were you attempting to do?
  We were trying to deploy multiple war files with this buildpack.

• What did you expect to happen?
  All the wars to be deployed to tomcat.

• What was the actual behavior? Please provide log output, if possible.
  Detection failed.

I know currently there are workarounds to this issue, but it would be nice to have a more native support for it.

[dmikusa]

A discussion around this came up in Slack. Adding some notes here.

1. If given a directory with WAR files in it, the Tomcat buildpack appears to be detecting correctly. I believe this is because Tomcat will always pass detection if it thinks that a source build is happening. In this case, it thinks a source build is happening, so it passes. That should be sufficient.
2. Presently, Tomcat buildpack fails at build time because it marks itself as unmet. This is where it re-checks the workspace for a WAR file. If there was a source build, the workspace would now be an exploded WAR (the output from build)
3. To make it support WARs, build.go would need to be changed to check for *.war (or probably some configurable pattern). If found, then “deploy” the WARs it finds.
4. There are multiple ways to “deploy” a WAR. I think a little investigation would be necessary. My thoughts...
   • I think we’d want to leave the WAR files in the /workspace directory. I can't see an advantage to copying them to a layer. It's just extra I/O.
   • I think we could either add a symlink to Tomcat's webapps/ directory for each WAR, or we could configure Tomcat to use /workspace as the webapps/ directory. I'm leaning toward the latter, but both would require slight adjustments to Tomcat's configuration.
   • It might also be nice to explode the WARs for Tomcat (also should be configurable). This would save some time when the app starts up. It would also prevent Tomcat from needing to write the files it extracts somewhere (/tmp being the only place it could write them at runtime).