OpenJdkVendor

Now that we are running with full OpenJDK 1.7, merging with vendor branches is less critical. However, we should still keep up to date with bug fixes in 1.7 and will eventually need to update to 1.8.

These instructions have not been reviewed for some time and may need updating.

Updating and Merging our OpenJDK Vendor Branch

OpenJML is based upon OpenJDK.

A snapshot of the OpenJDK code base relevant to OpenJML is located in an SVN vendor branch at [source:OpenJML/vendor/OpenJDK/].

When a new release of the OpenJDK is dropped, this branch is updated appropriately and committed to our repository. This is accomplished in around a dozen steps:

1. Checkout and/or update a Mercurial sandbox against the OpenJDK repository.
2. Ensure your SVN sandbox for the [source:OpenJML/vendor/OpenJDK/ OpenJDK vendor branch] is up-to-date. Call this revision number 'O'. (More information on the organization of the OpenJDK repository is available here.) Note that the forest extension of Mercurial is necessary to correctly access the OpenJDK repository.
3. Update all files in the SVN sandbox with the corresponding files in the Mercurial sandbox. This can be accomplished with intelligent use of tar, rsync, find/rm, and other similar tools.
4. Perform a diff -rq of the two trees to ensure that they are identical.
5. Do not forget to svn add and svn del the resulting sandbox appropriately.
6. Commit the new snapshot in SVN with a message that indicates which drop we have synchronized to. Call this revision number 'N'.
7. Use svn merge to merge in all changes between 'O' and 'N' from the vendor branch to your (perhaps mainline) development branch or trunk. E.g., run svn merge -r 1253:2297 $WORKSPACE_ROOT/OpenJDK-vendor/src/share/ . while sitting in $WORKSPACE_ROOTOpenJDK/trunk/langtools/src/share for some appropriate WORKSPACE_ROOT value.
8. Resolve all conflicts in the merge, paying careful attention to all files/lines comment with DRC, JRK, or DMZ.
9. Once the merge builds in Eclipse, commit it with an appropriate message.
10. Run all unit and system tests and fix all outstanding issues.
11. Commit the resulting tested merge with an appropriate message.
12. Profit! No, actually, announce to the jmlspecs-developer mailing list, please.