OpenArbor Development Windows

This is how to setup a Windows development environment for developing OpenArbor, debugging OpenArbor, running the automated test system, and other project-management activities.

For a quick guide to building and installing OpenArbor, see OpenArbor Build.

See also OpenArbor Testing.

It is assumed that all command line operations will be done in a bash shell in a desk maintainer environment.

Download and install Eclipse

1. Download and extract \\nx3000\openarbor\Downloads\oadevkit_windows_2023-06-R.zip to C:\Eclipse\2023-06-R.
   • Note that extracting using Cygwin unzip doesn't work. Running the Cygwin extracted Eclipse generates an error: The Eclipse executable launcher was unable to locate its companion shared library."

 create directory C:\Eclipse\2023-06-R
 cp //nx3000/OpenArbor/Downloads/oadevkit_windows_2023-06-R.zip /cygdrive/c/Eclipse/2023-06-R
 Unzip files in 2023-06-R.
 Result: C:\Eclipse\2023-06-R\eclipse

Check out the development workspaces

mkdir -p /cygdrive/c/ddci_eclipse
svn co --username=<username> --password=<password> --no-auth-cache https://deos.ddci.com/svn/DDCI/products/openarbor/openarbor/branches /cygdrive/c/ddci_eclipse/branches

Workspace configuration

1. Create a desktop shortcut to: C:\Eclipse\2023-06-R\eclipse\eclipse.exe
   1. Name the shortcut 2023-06-R OA Dev
   2. Modify the properties of the shortcut to "Run As Administrator"
   3. Modify the target to be: C:\cygwin64\bin\run.exe /bin/python /desk/desk-environment.py C:\Eclipse\2023-06-R\eclipse\eclipse.exe
   4. Double-click the shortcut
2. Create a new workspace such as: C:\ddci_eclipse\workspace-<branchName>
   • Rationale: Branches come and go, and sometimes you just hose up your working copy. Keeping the workspace and the working copy separate makes it easier to switch branches or delete and re-download your SVN checkouts without having to worry about losing your workspace configuration.
3. Import Existing projects into workspace
   1. File->Import...->General->Existing Projects Into Workspace
   2. Browse... to C:\ddci_eclipse\branches\mainline\workspace
   3. OK
   4. Finish
4. Import the launch configurations.
   1. File->Import...->Run/Debug->Launch Configurations
      1. Set From Directory to C:\eclipse\eclipse\launches
      2. Check the launches checkbox.
         • The DDS Dev Launch is for debugging OpenArbor, the DDS Test Launch is for debugging tests.
   2. If this is your first launch, use Window->Preferences->Run/Debug->String Substitution to create the string substitution variables ddsBranchName, ddsConfigName and ddsName as per #Dds_Variables.
5. In Window->Preferences->Java->Editor->Save Actions
   1. Check the 'Perform the selected actions on save' box
6. Fix auto-props for both environments.
   1. In your DESK maintainer environment, edit /etc/subversion/config; change the line that says enable-auto-props = no to enable-auto-props = yes. You will also have to uncomment the preceding [miscellany].
   2. In Eclipse, go to Window->Preferences->Team->SVN and change the configuration location at the bottom to point to the /etc/subversion/ location of your maintainer environment, i.e., the result of the shell command cygpath -wa /etc/subversion/

1. To start OpenArbor: Run->Run Configurations...->Eclipse Application->DDS Dev Launch.

DDS Variables

The imported launch configurations use several environment variables to allow developers to easily switch between multiple installed DDS' when both developing and/or usring the automated test system. It is possible to test multiple bsp's for an installed DDS. The developer should only need to specify the ddsBranchName, ddsConfigName and ddsName. When a DDS is installed using the automated test system (OpenArbor_Testing), the DDS is installed at C:\oatestharness\workspace\DDS-list\$(ddsName). A workspace for that DDS is created at C:\oatestharness\workspace \ddses\$(ddsName\$(ddsConfigName)\workspace.

Variable	Example Value	Description
ddsBranchName	mainline	Must match the SVN branch name under development/test. Used by the testSystemInvocation variable to form the --branchRoot option to the test system.
ddsConfigName	deos_ppc_qemu	Indicates the bsp under development/test. Used by the launch configurations to location the DDS workspace directory.
ddsName	DDS-pikayo-deos-multicore-20160111	Indicates the dds under development/test. Used by the deosInstallDir and testWorkspacePrefix variables to locate the DDS installation directory and DDS workspace directory.
username	scoretest	Ubuntu only: indicates user for launching tests

Installing Experimental Packages

Sometimes, you may want to test changes to the cygwin package scripts or package structure without pushing anything to a live server. This can be done by using an existing DDS as a base to modify.

1. Download the DDS you want to use as a base for your changes and put it somewhere.
2. Drill down into {DDS_LOC}/deos-heartos-posix/deos/{PACKAGE_NAME} to find the tar.bz2 you want to modify. Make a backup copy just in case.
3. make a temporary directory somewhere, and extract the contents of the tar.bz2 to the temporary directory, using tar -xjvf.
4. extract the contents of the tar file to this same temporary directory as well
5. You will likely have two directories "etc" and "<some package dir (ie. OpenArbor>". Modify the contents of either director as required.
6. To re-zip the updated directories, issue the following command at the top-most level of the temporary directory containing the updated files: tar jcvf {PACKAGE_NAME} {dir1} {dir2} (ie. tar jcvf trac-docs-258-4.tar.bz2 etc TRAC_)
7. Find the setup.ini file in {DDS_LOC}/deos-heartos-posix/, and find your package name inside this file.
8. Use md5sum to recalculate your new package, and ls -l to get the exact size of the new package. Replace the corresponding values in the setup.ini, and change the location of the archive, if you are using an alternative location.
9. The installer can now be run with the changes in place. Try it and see what happens.

• example line from setup.ini:
  • install: deos/trac-docs/trac-docs-258-4.tar.bz2 3308783 5ad42277e650bdc69a4be5fd48768071
    • size is 3308783 in the line above
    • md5sum is 5ad42277e650bdc69a4be5fd48768071 in the line above

Developing the OpenArbor Test Harness

1. make directory C:\ddci_eclipse_test_harness_dev
2. cd to the above directory and use svn to checkout a fresh copy of: https://deos.ddci.com/svn/DDCI/products/openarbor/utils/dds-manager/dds-manager-e4/
   
   1. svn co --username=<username> --password=<password> --no-auth-cache https://deos.ddci.com/svn/DDCI/products/openarbor/utils/dds-manager/dds-manager-e4/ dds-manager
3. Get the appropriate dev kit from \\nx3000\openarbor\Downloads
4. Use the devkit to open a worksapce at dds-manager
5. Import the existing project com.ddci.dds.manager
6. Create an Eclipse Application launch configuration:
   1. Main: Run a product: com.ddci.dds.manager.product
   2. Arguments: specify --deskRoot C:/cygwin or your maintainer location.
7. The overall structure of the test harness follows a client-server pattern. The user interface is backed by the client, which passes messages and commands back and forth with the server. The server keeps the clients updated with its status, and executes commands sent by the client. Every test harness is both a client and a server. This includes localhost.
8. The commands that the test harness can perform are arranged in a stateful dependency hierarchy, in order to streamline the usage process.

   1. add          stop nuke
      |
      install
      ____|_____
      |    |     |
      run  test setup
      
      zip
      

   2. Add, install, run, test, and setup have a dependency graph between them, so that commands can ensure any necessary preceding commands are complete, or re-run if necessary.
   3. Stop and nuke can be invoked at any time, they should always do the correct thing.
   4. Zip technically requires testing to have been done, but there is not a direct dependency because user action is required between the two.