This document is in DRAFT.

Institutional Builds are the way to make customisations for your Redbox/Mint implementation and creating one is the first step to moving from a Demo/Evaluation installation to one that will be suitable for your needs in production. Institutional Builds allow you to configure/customise:

Before you start this procedure, please make sure that you have Apache Maven installed correctly. 

There is a fair bit of configuration in these institutional build pom files that is needed to make it work. Ideally we would set up an archetype for institutional builds but at this stage the best way to get this configuration is to get this is to take a copy of one of an existing demonstration build, any archetype that we would create would most likely be very similar to the dev-local build. To take a copy, clone the git repository and then remove the .git directory in the root directory of the tree.

In our demonstration builds, our version always matches the version of redbox/mint we are working with. This is because they are sample builds that rarely have changes in them apart from updating the redbox/mint version it is using. In a real world scenario, this institutional build is your development project and as such may have a life of it's own that is somewhat separate to what is happening to the core of the code. For this reason, we recommend using your own version number system (as I have done in the above sample code). Here's an explanation of Maven versioning 

You may like to consider various plugins for use in your build. Check out our Plugin Directory for a list of available plugins.

There are so many different things you can customise in your ReDBox/Mint instance, I will only cover it in general terms here. For more in depth information on customising specific aspects of the system, check the How-to section regularly. Looking at the project structure you can see that it follows the same structure as what is outputted post build but with only the files that have been customised.

Institutional Build Structure

Customising is as simple as grabbing the file you want to change and putting it in the equivalent place in your institutional build structure and making the modifications. New files that appear in this tree structure will also appear in your final build.

To build your institutional build, simply type at the command prompt: 

This will build the application and output all the directories ready for you to run it. This is fine for development, but what if you are building the application on a build server to deploy to testing servers or production? In the next step, we discuss how to manage this.

The command given in step 4 will build the application and output all the directories in place, but what if you need to deploy to another server? The institutional builds are set up with a custom profile that you can specify if you want to build a tarball in your target directory (.tar.gz file) that you can upload to a server (or Nexus as is discussed in Step 7). The command to type at the command prompt is:

Taking this one step further, your test servers and production server are almost certainly going to require different configuration to run correctly once deployed. Changing the values of these properties once you've extracted the tarball on the server is one way of handling this but is error prone and means your deployments aren't guaranteed to be "repeatable". A better way to handle this situation is to create profiles in your pom file for each environment and specify them at build time.

  

Once we have a profile set up as above, the command to type at the command prompt is:

 mvn clean package -P uat,build-package