Skip to content

HLSW Meeting, 2016 03 11

Jump to bottom
Shane Walker edited this page Mar 11, 2016 · 4 revisions

In the context of ongoing work on the seqexec webapp and the promise it holds for a future web-based OT, we met to discuss associated technologies and potential sweeping changes.

Scala.js

Barring unforeseen complications we all agreed that Scala.js will be used for developing web applications but noted that it will require changes to the build and to model software to support cross building. Namely:

  • Any part of the model to be used in a client must be written in Scala.
  • Any dependency must provide a cross-built version for Scala.js, which somewhat complicates upgrading and maintenance.
  • Cross building in the current OCS build would likely be difficult.

ReactJS

We did not dwell on client side technologies but agreed that ReactJS seems like a viable alternative.

Web Server Options

This discussion is still pending. In the context of dependency management, we noted that the constellation of Typelevel and Typelevel-ish libraries tend to evolve together. This mitigates to some extent the future instability of the scalaz/cats split, the port of scalaz-stream to be be independent of both, etc.

OSGi

We discussed OSGi and decided that we will not be using it in the upcoming model and application rework. There are a some clear benefits to moving away from OSGi:

  • Simplifies the build significantly and (probably) makes it load quicker.
  • Opens up the possibility of directly importing sbt projects in Idea, though we aren't entirely sure how well that works with large multi-part projects. There is also an existing Idea build file generator sbt plugin that we can try if we run into problems.
  • Will no longer need to add OSGi headers to library jars and we should be able to use managed dependencies for most things.

We identified several things provided by OSGi today that will have to be done differently in the future:

  • App Launchers. We will need application launchers for each application. They will do the wiring of required bundles. (It may take a while to stop using the term "bundle".)

  • Remote Shell. OSGi provides us with a remote shell for administration commands. These will have to be replaced. One attractive option is to provide a web-based API for commands (like rmprog, exportXml, etc.). These can then be accessed via curl and shell scripts can make them easier to use.

  • Startlevel / Lifecycle. We have at least two areas where it is convenient to be able to raise and lower the startlevel and thereby control which services are running:

    • Before an upgrade we turn off external access to the ODB by lowering the startlevel.
    • We allow the ODB to startup and do some basic tests with it before turning on the Data Manager by raising the startlevel.

    This functionality will have to be replaced.

  • Code quality. Conflicting dependencies not an issue now but it could be easier to find different parts of the codebase using different versions of the same library. OSGi also ruled out questionable technologies like AspectJ and reflection. These things now have to be caught with peer review.

We agreed to keep OSGi for remaining releases based on the "OCS 2" model. The new seqexec and web client however should assume that they will not be using OSGi.

Build

We briefly discussed potential changes to the build beyond removing OSGi. The initial idea was to split it into various pieces that share jars via a repository like Artifactory. There are advantages however to having all the OCS code together in a single project (with its own sub-projects). Most importantly, it simplifies refactoring parts of the model since you have all the code that uses it available to you in your IDE.

For now, we agreed to stick with the same multi-sub-project build structure that we have today. When we start working on "OCS 3", we will begin with nothing and add code on an as-needed basis. This should help us to remove cruft that has built up over the years.

The seqexec (or maybe just the web-client?) should be done with a new OSGi-free build. That will mean exporting parts of the spModel that it needs to Artifactory for consumption.

Clone this wiki locally