HLSW Meeting, 2016 03 23

Following on the previous meeting, we met to talk about the seqexec build, http4s vs play for webapp backends, and testing frameworks.

Seqexec Build

We decided that we are likely better served with a single large project with all of our modules rather than trying to split things up into various logical groups like SP Model, ODB, OT, etc. Our goal with OCS3 is to keep the build as simple as possible and there is no clear consensus in the community for how to best organize large codebase builds anyway. In fact organizations like Twitter use the single-project approach.

The work Carlos is doing on the OSGi-free seqexec application will serve as a starting point for the OCS3 approach. We agreed to go ahead and move the seqexec server development to that build as well. It will have to pull in the bits of the SP Model that it uses from published snapshots in our artifactory repository for now. In time the parts of the model that survive into OCS3 will be added.

We agreed to place all the modules into one directory, though within each module the build will often be split into js, jvm, and shared areas for Scala.js. Carlos will make a few updates to his seqexec build and then bring it over to a repository in the main gemini-hlsw account so that we can easily share it and do PRs as usual.

Http4s vs Play

We had a brief discussion about webapp backend solutions. The tradeoffs seem fairly clear, though more experience with both of them might help to make the decision.

• Play is fully working, mature, and fairly well documented. A caveat though is that the "embedded" Play option that we are using is fairly new and may be a bit under-documented.

• Play is part of Lightbend so the support picture isn't clear. The http4s developers are available and open for questions on gitter.

• Both options bring with them a number of dependencies, though Play adds ~15 or so more than http4s.

• One particular http4s dependency which could be problematic is scalaz-stream, which brings a dependency on scalaz, which can make the dependency and update situation more complicated since we use a number of scalaz-dependent libraries. The good news is that scalaz-stream is turning into FS2 which has no dependencies in its core library. The http4s guys will release a version using FS2 when it is ready.

• Http4s is smaller, more modular (?) and, I think, fits in better with the functional programming emphasis we have adopted.

We expect that our needs are fairly simple regardless. We decided that given time, Carlos will try to keep both options working and thereby gain more experience with each. Since we aren't going to be heavily invested in either option, we don't believe there are significant drawbacks to waiting on making a final decision.

Testing Frameworks

We touched on testing frameworks briefly. In particular specs2 is proving problematic because it requires a specific version of scalaz which complicates updating other libraries using scalaz. For me personally, ScalaCheck support is more important than any of the other specific features of specs2. ScalaCheck can be used with ScalaTest just as well and it has no scalaz dependency.

Rob identified scalaprops as well as an option we should consider for OCS3.

For now, the seqexec and its webapp will not use specs2 in order to avoid the scalaz dependency issue.