Resources are included in your jar/war file, while an assembly creates a zip or tar.gz file
EJC - yep - I got that, but both the resources stanza and the assembly descriptor(s) can filter files. We have a process where we want the build to generate a war file, but hand that off to another custom, in-house plugin to generate an ear file. for example we create a tar.gz with our final war file EJC - we're already on divergent paths - we have a bunch of configuration inside the web.xml. Also, I'm not about to unpack something just to change a few things and then repack an archive during deployment. , the configuration files for the different environments EJC - woah - so if you have to deploy this web app to say, 20 or 30 different servers across multiple environments, you pack all that configuration in this war? Say your war is 150 mb, you really want to rebuild it each time someone corrects a setting? We don't here, but that's another story. , some static resources which are deployed somewhere else EJC - like web tier items? This is getting off the subject a bit. and the deployment documents. EJC - our apps are all internally consumed (live site), we have our site output generating the deployment notes in a separate mvn build structure. So the administrators have all the files they need to deploy our application. Filtering is used inside the war file, to display the current version on a status page. Two different things. EJC - So this leaves my question still open and unanswered. Why have a target/scripts directory when you can have a target/appName-version-dev/scripts where the appName-version-dev directory matches 100% what your deployed app looks like? Why duplicate the resource copying in the assembly descriptor? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
