You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Original approach was to upgrade one version of play at a time and keep all functionality. This turned out incredible difficult given all the interdependencies between libraries and scala version. See old branch: https://opensource.ncsa.illinois.edu/bitbucket/projects/CATS/repos/clowder/compare/commits?sourceBranch=refs%2Fheads%2F2.0&targetBranch=refs%2Fheads%2Fdevelop.

Currently working on this: Luigi Marini Rob Kooper Maxwell Burnette Todd Nicholson

New approach is as follows:

  • Remove all unused and legacy code. This will be 2.0.
    • XML RDF export
    • Rabbitmq monitoring using manager API (Maxwell Burnette started on this)
    • Geostreams API
    • Deprecated endpoints
    • Every plugin should become a Guice Trait + Implementation (2.1?)
      • For services that are not implemented, provide an no-op implementation
      • Enabled/disabled, is it in the config? Is it a common trait and the ability to provide implementation class in config file?
    • ??? (Add by end of this week Nov. 1st)
  • Elasticsearch upgrade?
  • New MongoDB implementation. This will be 3.0+.
  • Modify code to be compatible with newer versions of Playframework. 4.0+
  • How do tests factor in? can we start writing them before the refactoring? For example unit tests of services vs play scala tests of controllers actions.
  • Enforce style as part of this process. Using IDE? We should look at what rules and style software to use.


Play 2.6 Upgrade

 

Sbt migration: http://www.scala-sbt.org/0.13/docs/Migrating-from-sbt-012x.html

  • No labels