Best maven practices for modifying built war-file with generated resources

Question

Currently I'm working on integrating grunt build process to our maven build process. Here are two options I can think of:

1. Pointing some folder in resources as a target build dir for grunt project.
2. Building grunt project wherever and enlisting this this non-standard folders as included resources in the pom.xml.

It looks like there is yet some space to enhancement. Basically, since grunt subproject does not depend on any external resources, it would be nice to learn how not to rebuild war-file that had been already compiled, but modify it after rebuilding grunt-project.

So, the question is: What are the best practices adding generated resources to an existing war file.

Answer 1

The approach of adding resources to a war file amounts to modifying a maven-built artifact after maven builds it. That runs counter to the maven philosophy of tightly controlling the entire build of every artifact. You really have three choices:

1. Include the grunt generated source in the war's source and build a single artifact with maven. In this case you rebuild the war every time grunt resources change, or
2. Put the grunt generated sources in a second maven artifact and make that artifact a dependency of the war artifact. Maven will still rebuild the war every time, but you get the separation of builds you seem to be implying in your question, or
3. Make the dependency in (2) a runtime dependency, if possible. You basically make the scope of the grunt artifact dependency "provided" so you don't have to rebuild the war every time your grunt artifacts change. You only have to rebuild your grunt artifact.

It sounds like you want to go with option (3).

Answer 2

A war file is just a zip file with a certain file layout, you could just add to the archive using a zip tool. For example my linux platform zip command has the -g command.

-g --grow Grow (append to) the specified zip archive, instead of creating a new one. If this operation fails, zip attempts to restore the archive to its original state. If the restoration fails, the archive might become corrupted. This option is ignored when there's no existing archive or when at least one archive member must be updated or deleted.