Skip to content

Building Phase I tools

Jump to bottom
Carlos Quiroz edited this page Jan 20, 2016 · 6 revisions

A typical Phase I release contains the following tools:

  • PIT
  • P1PdfMaker
  • p1 schema

To build PIT for OSX, Windows, Linux32 and Linux64 do

project app_pit
ocsDistAll

Alternatively you can build each platform

ocsDist MacOS

To build P1PdfMaker (Only on Linux) do

project app_p1_pdfmaker
ocsDistAll

For the p1-schema we make a tarball with the xsd files. Do:

project bundle_edu_gemini_model_p1
modelDist

The binaries are stored on the usual place

app/pit/target/<version>/<platform>

Version Numbers

  • The version number has 3 digits and is edited in the top-level build.sbt. Like the OCS version number you set testing to "false" to make a production release, however there is an extra "test" flag that sets the PIT to use the test backends. Than one is set on app/pit/build.sbt. The flag edu.gemini.pit.test is defined as a property and only its presence is checked not its value, therefore for production it should be removed.
  props = Map(
    "org.osgi.framework.storage.clean"        -> "onFirstInit",
    "org.osgi.framework.startlevel.beginning" -> "100",
    "org.osgi.framework.bootdelegation"       -> "*",
    "edu.gemini.pit.test"                     -> "true", // Remove for production
    "edu.gemini.ags.host"                     -> "gnodb.gemini.edu",
    "edu.gemini.ags.port"                     -> "8443"
  ),
  • Despite the 3rd digit in the version number, only the first two are respected in the application name (though they appear in the distribution files). Therefore, the last digit in practice is always 0 (?) For example, PIT production version 2016A.1.1 is specified with this entry:
pitVersion in ThisBuild := OcsVersion("2016A", false, 1, 1, 0)

  • The digits on the version are meaningful with respect to the schema version as follows

    2016A.(Semester).(Minor)

Where Semester can be either 1 corresponding to A and 2 corresponding to B. The minor digit, is an increasing number that indicates changes on the schema. It starts at 1.

For example the typical first version for an A semester will have version

2016A.1.1

For the B semester it will be

2016B.2.1

  • The version number creates a distinct XML schema version which is validated when adding skeletons and (probably) in ITAC as well.

  • Though it hasn't been done, there could be a good opportunity to make use of the 3rd digit, e.g. to make a trivial label change to the PIT app, produce a distinct version for it, and yet not break skeleton imports, backends or p1-monitor.

Clone this wiki locally