Omit files from a source directory during deployment?
October 29, 2010 11:25 AM Subscribe
How can I set up a software build that not only copies files but uncopies them as well?
This is kind of a weird application. We have a .WAR file with a "default" application in it (Alfresco default web app, for reference). We have a custom source base outside of that WAR consisting of files we want to add on top of the default installation. That part's easy, the build can just unzip the WAR, copy the source files over it, and rezip into a distribution directory.
The complication is that we also want to specify files to *delete* from the default application before the rezipping step. About 15 files that are in the original app but we want to omit from the deployment.
What's a good way to implement this? I'd like to make it as transparent and intuitive to the developers as possible; listing the filenames verbatim in the build script would be a last resort, for example. Thoughts?
This is kind of a weird application. We have a .WAR file with a "default" application in it (Alfresco default web app, for reference). We have a custom source base outside of that WAR consisting of files we want to add on top of the default installation. That part's easy, the build can just unzip the WAR, copy the source files over it, and rezip into a distribution directory.
The complication is that we also want to specify files to *delete* from the default application before the rezipping step. About 15 files that are in the original app but we want to omit from the deployment.
What's a good way to implement this? I'd like to make it as transparent and intuitive to the developers as possible; listing the filenames verbatim in the build script would be a last resort, for example. Thoughts?
I have a build system that spits out a war file + additions with some gunk [non-english help files] optionally removed.
It uncompresses the stock WAR into a war-base directory, deletes the appropriate stuff, copies in the additions, then zips it up. The files and directories to be deleted are called out by name in the build script. If that war-base directory gets deleted, it's rebuilt from the source.
Like mikeh says, you're going to have to define the "bad" files somehow, whether that be by wildcard, directory path, or individual filename. If it's not in the build script, it'll have to be in some other script or file.
You could build a new base war, but then remember that you'll need to record somewhere that this base war is different from the stock source war in this and that way, and perhaps provide an automated way to regenerate it.
It seems to me that this is an intrinsic part of this software build, and as such the list of files to delete [or the heuristic that determines the list of files to delete] belongs in the build script. What I like about this method as opposed to the new base war is that to do a new build all someone needs is the stock source war, not some specially-prepared one.
I suppose you could break the file deletion [or new-base-war-creation] bit out into a second build script, which could be personalized for this or that developer or context, or disabled altogether by a build flag or somesuch.
posted by chazlarson at 1:35 PM on October 29, 2010
It uncompresses the stock WAR into a war-base directory, deletes the appropriate stuff, copies in the additions, then zips it up. The files and directories to be deleted are called out by name in the build script. If that war-base directory gets deleted, it's rebuilt from the source.
Like mikeh says, you're going to have to define the "bad" files somehow, whether that be by wildcard, directory path, or individual filename. If it's not in the build script, it'll have to be in some other script or file.
You could build a new base war, but then remember that you'll need to record somewhere that this base war is different from the stock source war in this and that way, and perhaps provide an automated way to regenerate it.
It seems to me that this is an intrinsic part of this software build, and as such the list of files to delete [or the heuristic that determines the list of files to delete] belongs in the build script. What I like about this method as opposed to the new base war is that to do a new build all someone needs is the stock source war, not some specially-prepared one.
I suppose you could break the file deletion [or new-base-war-creation] bit out into a second build script, which could be personalized for this or that developer or context, or disabled altogether by a build flag or somesuch.
posted by chazlarson at 1:35 PM on October 29, 2010
You can make it a bit simpler by keeping a list of files to exclude in the custom files that you add. You then just have to keep that file updated along with the other custom files you have.
So you're going to have to have some list somewhere of the files that you don't want in your custom app, might as well keep that list with your custom additions to the default app and just use it as an exclude list when you create the custom app archive. The exclude list will let you use files, directories, wildcard matching... have to check the documentation for whatever version of zip you are using.
posted by zengargoyle at 6:06 PM on October 29, 2010
unzip default-app.war
copy path/to/custom/files default-app #custom files + exclude.lst
zip -r custom.war default-app -x@default-app/exclude.lst
exclude.lst would contain a list of the files that you didn't want included in the custom.war that you're creating (don't forget to include exclude.lst itself). I'm not a Windows/zip/war user but here's the gitst:
$ ls
default.zip my-custom
$ unzip default.zip
Archive: default.zip
creating: default/
creating: default/b/
creating: default/a/
$ mv default custom
$ cat my-custom/exclude.lst
custom/a/
custom/exclude.lst
$ cp -rv my-custom/* custom/
`my-custom/c' -> `custom/c'
`my-custom/d' -> `custom/d'
`my-custom/exclude.lst' -> `custom/exclude.lst'
$ zip -r custom.zip custom -x@custom/exclude.lst
adding: custom/ (stored 0%)
adding: custom/b/ (stored 0%)
adding: custom/d/ (stored 0%)
adding: custom/c/ (stored 0%)
$ unzip -l custom.zip
Archive: custom.zip
Length Date Time Name
--------- ---------- ----- ----
0 2010-10-29 17:54 custom/
0 2010-10-29 17:29 custom/b/
0 2010-10-29 17:54 custom/d/
0 2010-10-29 17:54 custom/c/
--------- -------
0 4 files
# custom/a and custom/exclude.lst not present...
So you're going to have to have some list somewhere of the files that you don't want in your custom app, might as well keep that list with your custom additions to the default app and just use it as an exclude list when you create the custom app archive. The exclude list will let you use files, directories, wildcard matching... have to check the documentation for whatever version of zip you are using.
posted by zengargoyle at 6:06 PM on October 29, 2010
« Older Can you point me to 3D models I can move and zoom... | Which is less sanitary: not washing your hands... Newer »
This thread is closed to new comments.
2. Specify those files in the build script.
I am not sure what you mean that listing the files would be a last resort -- unless there's a specific way to group them by another commonality, then the only obvious way is make an exclusion list.
posted by mikeh at 11:29 AM on October 29, 2010