The Grouper distribution has a build script for one environment. If you need to manage dev/test/prod for the loader/ui/ws that is 9 environments. When you need to upgrade, it can be time consuming and easy to make mistakes.
This is a strategy we use at Penn to manage all the config files and build scripts for all the environments, without duplication, and storing files in CVS. This is probably not a strategy that can be used without modification, but you can use the design and tweak the scripts for your environments.
Note that this uses ant, not Maven.
Here is the example output. Note the UI and WS zips just have a warfile inside, but since the warfiles in this case (configurable in build.properties) have the same name, so we zip them in different names so they can live in the same dir.
Here is the folder structure:
- appSpecific: holds files for grouper a grouper component that is different from a grouper build, and different in various envs. Generally config files or UI customizations for an institution
- appSpecificNoFilter: holds files like appSpecific, but will be copied without filtering (search/replace) variables (e.g. the passwords in each env differ). These are files without variables, or binary files
- buildFiles: holds build.properties for Grouper builds
- conf: common grouper API config files which are different than the default or which differ in various environments
- dist: the builds go there
- docs: documentation
- grouper-ui-webapp: a build of the UI without files which different for institution or files which different per env
- grouper-ws-webapp: a build of the WS without files which different for institution or files which different per env
- grouperClient: the binary grouper client without files specific for an institution
- lib: ant library for if's in build script
- temp: used for builds
- the build.xml and build.example.properties are in the base dir
Setup and Maintenance
This section describes a new setup, or an upgrade (the CVS syncs)
- Create that folder structure above e.g. in C:\dev\eclipse\projects\pennGrouper
- Download the later Grouper API binary, UI, WS, and client (binary)
- E.g. in C:\software\grouper\1.5.2\grouper.apiBinary-1.5.2
- E.g. in C:\software\grouper\1.5.2\grouper.clientBinary-1.5.2
- E.g. in C:\software\grouper\1.5.2\grouper.ui-1.5.2
- E.g. in C:\software\grouper\1.5.2\grouper.ws-1.5.2
- Copy all the build.example.properties to build.properties in each of the 4. Look at the build.properties, copy the file to the buildFiles dir. Sync with CVS and diff to see if there are changes (if not new). If there are changes, then copy the file back to its original location
- Example of changes, in the WS and UI build.properties, put the path to Grouper in there.
- Run "ant dist" in the UI and WS
- Edit this build.properties, and put in the locations to everything
- Run the ant task: copyGrouperApiFilesToBuildProject. This will copy the grouper config files to the conf directory. If this is an upgrade, compare the files with the latest in CVS and merge your changes. Otherwise look at the files and make changes as necessary. However, if you have something which differs per env, put a variable in there. In this case, here are my variables in grouper.properties:
There are corresponding entries in the build.properties:
Here are the variables in the log4j.properties:
This is the one place where the data is different per env and grouper module (well, mine are similar since I run on different servers, but they can be different). Here are the build.properties entries
Here are the grouper.hibernate.properties variables
There are entries per env. Note the passwords are encrypted with the morphString Internet2 library, so the encrypted values are in a file system file (better for storage of config files in CVS nad hiding plaintext passwords)
grouper-loader.properties (in appSpecific/conf instead of conf since only needed in the loader) also has a variable for the report directory and loader servers and passes:
These are in the build.properties
UI build scripts
Run the ant task: copyGrouperUiToBuildProject (note this assumes you ran the UI build target: dist). This will copy the build of the UI to the pennGrouper dir, but leaves out the grouper config files (since those are int he conf dir).
You can run the ant task: packageUi which will build the three UI warfiles and zips for dev, test, and prod
WS build scripts
Run the ant task: copyGrouperWsToBuildProject. This will copy the build of the WS to the pennGrouper dir, but leaves out the grouper config files (since those are int he conf dir). Note, if this is an upgrade, sync the appSpecific\ws\WEB-INF\classes\grouper-ws.properties and compare and merge with old values.
You can run the ant task: packageWs which will build the three WS warfiles and zips for dev, test, and prod
Client build scripts
See the setting in the build.properties to control the name of the client zip
Run this target: copyGrouperClientToBuildProject. This copies the binary client to the grouperClient dir so it can be saved in CVS. If this is an upgrade, compare the appSpecific\client\grouper.client.properties and appSpecific\client\grouper.client.usage.txt and put in the institution specific settings.
Run the target: packageClient to build the client zip for distribution in your institution. Note there isnt one for each env since the user can adjust the URL to connect to. Might want to give some examples of test envs in the properties file comments, unless you dont want to for security or to not confuse people.
Loader project build scripts
At Penn we run the loader in a webapp. So we need the grouper API and config files in the webapp. That webapp has dev/test/prod envs so we need to make sure the config files are currect. Configure the location of the project in the build.properties, the config dirs for each env, and also the log directories for the 4 envs
Run the ant task: copyBuildProjectToWebapp which will copy the grouper jars to the lib dir, and the config files to each location above (and substitute variables). The building of the webapp is done by that application.