These are the steps to verify core functionality of Java high level applications (HLA) when releasing new versions.
Any applications currently using CVS as their version control system should be migrated to Git as soon as possible using the eco cvs2git
tool.
Run: (assumes proper AFS ACL permissions have been granted)
$ eco cvs2git |
Enter the name of the module as it appears in the /afs/slac/g/lcls/cvs/CVSROOT/modules
file
A bare Git repo will be generated under $GITROOT
in the path you specified in step (3). (The previous CVS history and metadata will be migrated to the new Git repo automagically)
Verify that the new Git repo contains all of the previous CVS history and metadata by using the eco
tool:
$ cd /path/to/working/directory $ eco <module_name> $ cd /path/to/git/clone/repo $ git log |
Java HLAs are now deployed as static builds with their Java library dependencies built and checked in with the project (typically in a lib
folder in the project's root directory).
Re-build order with new Java version:
1. Update JCA (EPICS extensions)/3rd party source
2. xal4lcls (include new jca.jar from previous step, update ojdbc5.jar from $ORACLE_HOME if needed)
3. MessageLogAPI (dependency for hlaCommon)
4. hlaCommon (update compile source and target in build.xml)
5. hlaExtensions (update compile source and target in build.xml)
6. APIs (MPSConfig, TimingPatternChooser, etc.)
7. HLAs
You may also want to use visual panels to communicate related information, tips or things users need to be aware of. |
Related articles appear here based on the labels you select. Click to edit the macro and add or change labels.
|