Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info

A video describing the process can be found here: LOUIBuildProcess.mp4.

 It would be best to download this video and view it first. The file is ~ 100MB.

The process of building and pushing products to the machines at DCT is mostly a manual process which should probably be automated at some point in the future. The basic process flow is:

  • Set up a proper build environment
  • Update the work space from the repository
  • Modify about.mappings and plugin.xml files to reflect the new version number
  • Export the product using the correct platform; joe uses linux (gtk/x86_64) and all others use macosx (cocoa/x86_64)
  • Transfer the product to the appropriate machine at Happy Jack
  • Update the alias on the desktop

Build Environment

I recommend to have separate build and development environments for any one who is going to work extensively on the code. If the changes are very minor, one can use the build environment to make changes and test them before building the product. Fundamentally there is no difference between the two except the name and the idea of isolation. There are instructions on Confluence for setting up the proper environment.

Synchronizing with Repository

The first step in the process of building products is to update the workspace from the repository. If one has made code changes in the build environment, update first. Then test the product and if every thing looks good, commit the changes. Update again and start building if every thing looks good.

The update process causes eclipse to automatically recompile and rebuild the work space. This process does NOT build products.

Update Version Number

When every thing looks good, it is recommended to increment the version number for the products. The current policy is that unless it is a very minor change, all the products are built at the same time and would have the same version number. The LOUIs store the version number in two places and both need to be updated; about.mappings and plugin.xml files.

Export Product

The best way to understand the export process is to watch the movie. This section is meant as complimentary.

There are lots of plugins that comprise the products but in order to build a product, one needs to only deal with the top level plugin which defines the product. Currently we have the following products:

  • edu.lowell.lig.getTemp
  • edu.lowell.lig.joe
  • edu.lowell.lig.joe.client
  • edu.lowell.lig.observer.targetlist
  • edu.lowell.loui.cat
  • edu.lowell.loui.deveny
  • edu.lowell.loui.gwaves.guider
  • edu.lowell.loui.gwaves.wfs
  • edu.lowell.loui.igrins
  • edu.lowell.loui.inputValidator
  • edu.lowell.loui.lmi
  • edu.lowell.loui.nightlyreport
  • edu.lowell.loui.nihts
  • edu.lowell.loui.omspdu

Under the current architecture, all these products, except edu.lowell.lig.joe run under MacOS X. edu.lowell.lig.joe runs under Linux. To export a product, we follow the following general steps:

  1. Open the top level plugin for the product (one of the above plugins) in the Package Explorer view.
  2. There should be a file with the name of the product and .product extension, e.g. observerTargetList.product
  3. Open the file by double clicking and you should see a view with multiple tabs at the bottom. Select Overview if not already selected.
  4. In the Exporting widget on the bottom right, click Eclipse Product export Wizard
  5. The dialog box for the export wizard comes up and on the first page 
    1. Modify the root directory to reflect the new version number
    2. Modify the location for archive file to include the current date
    3. Make sure the bottom 2 check boxes are clicked
    4. Click Next
  6. On the second page of the wizard select the proper platform for the export
    1. linux (gtk/x86_64) for joe
    2. macosx (cocoa/x86_64) for all others
    3. Click Finish

The process of building and archiving the product takes a while and one needs to be patient. Other operations can be done while exporting a product except exporting another product. So the most efficient way to proceed is to set up and update the parameters for the next build while the first one is in progress. After the setup is complete click Finish and a blocking dialog box comes up informing the user that a build is already in progress and it waits till the first one is finished. Proceed and build all the products and put them in the same directory. Every product should have its own zip file.

Transfer Product

The products are transferred to three different systems:

  • dct-to1 - all products except joe
  • observing computer (baggins or dct-obs1/dct-obs2) will have the products used by observers:
    • LOUI_lmi
    • LOUI_DeVeny
    • LOUI_nihts
    • Observer Target List
    • Nightly Report
    • Input Validator
  • joe - joe the product

One of the reasons we export the product as a zip archive is that it make the process of transferring the files to the destination much easier.

Update Alias

All Products except joe

After transferring the files, they should be expanded and copied to /Applications/LOUI. It may be necessary to authenticate using the lig account credentials. The last thing to do is to update the desktop aliases to the current version. It is important to note that on dct-to1, the script that starts every thing for the operators calls the aliases on the desktop so there is no need to modify the script after the aliases have been update.

joe

The concept is the same but the process is a little different on joe. After transferring the relevant file to joe, ssh to joe and basically issue the following commands after making sure that joe is not running:

Code Block
languagebash
$ joe status
$ cd /opt
$ su
# cp ~joe/Downloads/RCP_Products/20170418/joe.linux.gtk.x86_64.zip ./
# unzip joe.linux.gtk.x86_64.zip
# rm joe.linux.gtk.x86_64.zip
# rm joe
# ln -s joe-3.8.2/ joe
# exit
$ emacs joeVersion.txt

...