Moves stores runtime config changes in a file called $\user.home}/sais-moves-web.properties. This is to manage properties which change at runtime. Moves also creates a folder called $\user.home}/sais-moves-web/ when interacting with subversion and maven. This page assumes that you're starting from scratch, so if these exist, stop OC4J, and rename these to $\user.home}/sais-moves-web.properties.backup and $\user.home}/sais-moves-web.backup respectively. That way you can be sure you are running in the most pristine state possible, and your screens should match those below.
It is assumed that you have been able to build and deploy moves, and can access the page http://localhost:8888/moves/admin/index.htm as outlined in Building and deploying moves locally.
The Build Configuration page
Click on the Build Configuration icon on http://localhost:8888/moves/admin/index.htm. There are 3 tabs on there.... one for Maven configuration, one for Subversion configuration and one for OC4J configuration. Let's start with each tab from simplest to most complex.
Build Configuration - OC4J tab
The only thing we need to know about oc4j is where the j2ee home folder is. This is so moves can find admin_client.jar, which it uses to deploy applications to containers. Below is a screenshot that I use on windows. Note that I use forward slashes rather than back slashes to separate the path. Back slashes are not supported in the current version of moves.
Click save when you have the oc4j tab configured.
Build Configuration - Subversion tab
Validate Subversion works as expected.
Before we look at Moves, let's first confirm that subversion works on the command line. If it doesn't work, moves certainly won't make it work.
- Open up a command prompt, and type set. You should see an entry like SVN_SSH="c:/Program Files/PuTTY/plink.exe". Make a note of it (including any quotes!). You'll need it later.
- type svn ls svn+ssh://svn.mit.edu/sais-sis-common/maven/releases/branches/playground
- If Subversion asks for your password on the command line, go back to Building and deploying moves locally and review the Kerberos and Subversion sections.
- If Subversion asks for your password in a kerberos window, then authenticate. The output should echo "pom.xml"
- If Subversion didn't ask for a password, and echoed "pom.xml", then you're good to go.
- type svn ls svn+ssh://svn.mit.edu/sais-sis-common/maven/releases/branches/playground. You should not be asked for a username or password this time, since kerberos will cache the authentication token for Subversion. If you are asked for a password a second time, go back to Building and deploying moves locally and review the Kerberos and Subversion sections.
- Open up a command shell and type * printenv | grep SVN_SSH*. This should return no matches
- type kinit, and authenticate
- type svn ls svn+ssh://svn.mit.edu/sais-sis-common/maven/releases/branches/playground
- If Subversion didn't ask for a password, and echoed "pom.xml", then you're good to go. If you are asked for a password, go back to Building and deploying moves locally and review the Kerberos and Subversion sections.
When you've successfully validated subversion, click on the Build Configuration icon, and select the Subversion tab. What we'll need to tell moves is
- Where is the Moves Component Registry
- How do you want to run Subversion
By default, moves will point to the production location of the Moves Component Registry (svn+ssh://svn.mit.edu/sais-sis-common/maven/releases/trunk). However, Developers who are testing moves will want to point to the Moves Playground Component Registry at svn+ssh://svn.mit.edu/sais-sis-common/maven/releases/branches/playground. So go ahead and change that.
If you are running on Unix/Linux, you can remove any Subversion Environment Variables. (REMEMBER to run kinit though, before you start Moves, or moves will hang, waiting on a username/password to be entered).
If you are running on Windows, add a Subversion Environment Variable called SVN_SSH with the value which you noted from "Validating Subversion on Windows" above.
Below is a screenshot for a typical Windows installation.
Testing your subversion setup
You an test your subversion setup by clicking on the "Build a release" workflow, and seeing if the drop down is populated with the MIT componenents. If it's not, look carefully at the "Show Log" link that is displayed on that page.
Build Configuration - Maven tab
This is the most complex of the tabs. What we're doing here is telling moves how to run maven.
- The Maven Command entry should be left as mvn (unless you're doing some really weird shenanigans)
- Check the Run Maven with Debug Output? checkbox if you want REALLY VERBOSE maven log files. Checking this causes mvn to be run with the -e and -X options. It is useful when you're having maven problems, as it will show stack traces and lots of logging. It's annoying when you're not having maven problems, so I suggest leaving it unchecked initially.
- Max Maven Build Time (in seconds) is SUPPOSED to kill a build if it hasn't completed in a certain time. This is not yet implemented... but might be some day.
- MIT Maven Repository (containing releases) should be the location of the MIT Maven release repository. Moves uses this to find released components and display them in the GUI. (Note that this field will hopefully go away in a future release, but for now it's critical, and for now, the default value *https://maven.mit.edu/nexus/content/groups/saisGroupRepo/* should be just fine).
- mit-release-plugin version. Moves uses the plugin edu.mit.maven.plugins:mit-release-plugin. The latest version can be found by browsing the MIT Maven repository.
- Maven System Properties can be left blank for local development environments.
- Maven Environment Variables are needed because on some OS's when you spawn a new shell, it may or may not inherit Environment Variables from OC4J's runtime environment. So what we are doing here is making sure the environment variables JAVA_HOME, SVN_SSH, M2_HOME, MAVEN_OPTS, PATH and SVN_SSH are set up correctly.
When Moves shells out to maven, it will add the environment variables shown. (Note that maven itself may fork another process, depending on the goals it is running. but we will discuss that later). It will also add any system properties to the command line with the -D option.
Below is a screenshot for a typical Production/Test installation.
And here is a screenshot for a developer installation on Windows
