Runway Metadata Update Process

1. Rebuild the database to ensure a clean DB
2. With your new Runway metadata schemas in runwaysdk-test/src/main/domain, run the import-schema-diff launch in the test project. This will create a .sql file in domain/ddl. Open this file and delete the first line (it will mention something about dynamic_properties). Scan through the rest of the file to ensure it only has SQL in it (and not, for example, log statements or Sys.out output).
3. Run the export-all-metadata launch. This will generate a new metadata.xml file in runwaysdk-server/src/main/resources/com/runwaysdk/resources/metadata. Open this directory up. DO NOT replace the old metadata.xml in runwaysdk-server. Replace the one in DDMS, and then delete the file from runwaysdk-server.
4. Increment the Runway version number in RunwayMetadataVersion.java. Remember the version number you picked as you will need it later.
5. Copy the sql diff file to runwaysdk-server/src/main/resources/domain. Commit and push and then tag (in the format like DDMS-1.22.0)
6. Create new runway jars (run as -> clean, run as -> install). Run the test rebuild database task to ensure your new metadata.xml file works.
7. Move your metadata schema from runwaysdk-test/src/main/domain to runwaysdk-test/src/main/domain/archive/sql. Commit your metadata schemas, your sql diff file, and RunwayMetadataVersion.java.
8. Test the sql diff files by patching an existing DDMS database and then booting tomcat and testing stuff. The easiest way to do this is to boot the DDMS test server, open a Postgres console and paste in your new metadata and run it. If the test server is not in a good state for this it may be OK to skip this step.
9. Copy your new runway jars to DDMS using the existing launch in the runway root project.
10. Copy the new metadata.xml to DDMS.
11. Commit the new runway jars and the new metadata.xml to DDMS.
12. Open the runway-patcher project (located in Assembla RunwaySDK_GIS) and open the patches directory. Create a new directory in here that matches the version number you specified in RunwayMetadataVersion.java.
13. Create a lib directory. Copy your new runway jars into this lib directory.
14. Create a sql directory. Underneath that create Postgis and Postgresql directories. Take your generated SQL diff file (from domain/ddl) and copy it to these directories. Rename it to match the paradigm that exists in the other patch files. You do this by removing everything in the file name except the relevant portion of the timestamp. What is most important is that the number of the file is greater than the number of the file in the pervious patch directory.
15. Open RunwayVersion.java in the runway-patcher project. Change the version number in this java file to be the same as the one specified in RunwayMetadataVersion.java.
16. In runway-patcher/launches, run the zip patcher launch.
17. Run a maven install on runway-patcher.
18. Commit RunwayVersion.java and your new patches directory to the runway-patcher project.
19. Open runway-patcher/target. You should have a runway-patcher-1.0.0.jar binary. Copy this binary to the lib directory of the ddms-runway-patcher project (located on the mdss repository) and overwrite the existing file.
20. Commit this new runway-patcher jar. Because its a large file, it will take some time.
21. Tag your last Runway commit with the Runway metadata version, i.e. DDMS-Metadata-1.22.0. Push your runway changes to upstream.
22. Test your new metadata files: 1. Create a fresh install. Run this SQL: SELECT * from dynamic_properties WHERE id='000000000000000000001'. It should output your new runway metadata version number. 2. Patch an older backup. Run the same SQL to ensure it has the correct version number. 3. Test your new features on both fresh install and patched to ensure the new metadata exists. 4. Ensure the Jenkins CI runway job passes with your new metadata file.