{"push_id":1371139535,"size":6,"distinct_size":6,"ref":"refs/heads/master","head":"d92fefe7e7f8e3aa84f2bcebb0c3e78182705443","before":"1848bb3aa5b4a12a7998f5b9fc0ec55adc946f0e","commits":[{"sha":"700cdcb05acb23db3e725879d68bba8a47a282e1","author":{"name":"Christopher Townson","email":"1ab404878e46d892882bc722116d6f5877434cec@gmail.com"},"message":"Step 2: update project/MicroService.scala and project/FrontendBuild.scala\n\nBy default, Play 2.5 uses a dependency-injection based routes generator that assumes controller classes are DI-based classes. However, it is advisable to avoid this cost of being forced to update all controllers during the initial migration. Therefore, the approach taken in HMRC libraries assumes that microservices and frontends are still using a StaticRoutesGenerator. This allows for backward compatibility with object-based controllers whilst permitting gradual migration to class-based, DI'd controllers (which can be handled via StaticRoutesGenerator by prefixing the route with an \"@\" in your routes file -- see play-health for an example).\n\nAdditionally, Play's SBT integration API has moved package from `play` to `play.sbt` so you need to update some references in your build files.\n\nIn project/MicroService.scala:\n\n1. Change references to `play.PlayScala` SBT plugin to `play.sbt.PlayScala`\n\nIn project/FrontendBuild.scala\n\n2. Change references to `play.PlayImport._` to `play.sbt.PlayImport._` ... your build should probably now be OK and the project should import (although you almost certainly have compilation errors)\n\nBack in project/MicroService.scala\n\n3. Add an `import play.sbt.routes.RoutesKeys.routesGenerator` statement\n\n4. Add `routesGenerator := StaticRoutesGenerator` to settings declarations\n\n5. Add `Resolver.jcenterRepo` to list of resolvers (we will need this later!)","distinct":true,"url":"https://api.github.com/repos/hmrc/example-play-25-frontend/commits/700cdcb05acb23db3e725879d68bba8a47a282e1"},{"sha":"aece9bf7e6e47bb1fd6cd6c7369726305d6cf873","author":{"name":"Christopher Townson","email":"1ab404878e46d892882bc722116d6f5877434cec@gmail.com"},"message":"Step 3: VERY IMPORTANT - update dependencies in project/FrontendBuild.scala\n\nUpdate your HMRC dependencies to the latest versions which are designed to support Play 2.5. See https://confluence.tools.tax.service.gov.uk/pages/viewpage.action?spaceKey=DTRG&title=Play+2.5.8+Upgrade+Guide for a full list of upgraded libraries. Upgrade any and all libraries listed in that Confluence page that you utilise.\n\nYou may also need to update your versions of 3rd party Play-dependent libraries, such as play-test and scalatest+play amongst others. It is important for YOU to verify that all of your dependencies are Play 2.5 compatible.\n\nIf you are seeing eviction warnings for Play 2.3, you MUST pay attention as they are almost certain to cause compilation failures (if you are lucky) or, more often, unexpected runtime errors. Not all evictions are a problem but ones relating to core play libraries are problematic.\n\nIt is quite possible that you depend on an HMRC library (possibly created by your team and only used by yourselves) that depends on Play but which has NOT been upgraded yet. In such cases, it is YOUR responsibility to upgrade the library.\n\nNote: play-json-logger should be replaced by logback-json-logger, which no longer depends on Play.\n\nAfter completing this step, it is almost certain that your project will still not compile.","distinct":true,"url":"https://api.github.com/repos/hmrc/example-play-25-frontend/commits/aece9bf7e6e47bb1fd6cd6c7369726305d6cf873"},{"sha":"e05e2fa6ec4162c935c35c74a82cdfa5d9f2bd19","author":{"name":"Christopher Townson","email":"1ab404878e46d892882bc722116d6f5877434cec@gmail.com"},"message":"Step 4: update metrics-play configuration\n\nMetrics is now provided as a Play module with a class-based DI controller. As a result, some changes are needed to configuration and tests to get it to work:\n\n1. Delete conf/play.plugins\n\n2. Enable the metrics module by adding `play.modules.enabled += \"com.kenshoo.play.metrics.PlayModule\"` in conf/application.conf\n\n3. Prefix the MetricsController route with an \"@\" in conf/prod.routes, as follows `GET        /admin/metrics             @com.kenshoo.play.metrics.MetricsController.metrics`\n\n4. In your integration or unigration tests, wherever you are using the hmrctest `WithFakeApplication`, add `override def bindModules = Seq(new PlayModule)` ... basically, you need to ensure that your \"fake applications\" contain the modules your app uses, otherwise you are liable to get test failures due to Guice provisioning errors. Finding these problems with tests can be a bit hit-and-miss, so you may prefer to wait to fix this type of runtime error until everything compiles. If you were sensible enough to use ready-made scalatest/Play test harnesses, then you won't have this problem as the updated versions of `OneAppPerSuite`, `OneServerPerSuite` et al handle all of this for you\n\n5. If you were using other Play plugins in play.plugins (with the exception of HMRC health the migration of which is handled for you), then you also need to ensure that you update to use \"moduled\" versions of these and declare them in your application.conf. There is an example repo for the HNRC's ReactiveMongo plugin at `example-play-25-mongo-microservice`.\n\nAfter this step has been completed, your project will still probably not compile. Hopefully, you have started seeing compilation errors related to filters, Messages and frontendGlobal, which are covered next.","distinct":true,"url":"https://api.github.com/repos/hmrc/example-play-25-frontend/commits/e05e2fa6ec4162c935c35c74a82cdfa5d9f2bd19"},{"sha":"8642da46ae1e2b563f8b38ec9099c94eb5cb608b","author":{"name":"Christopher Townson","email":"1ab404878e46d892882bc722116d6f5877434cec@gmail.com"},"message":"Step 5: fix the inevitable compilation errors\n\nIt is almost 100% certain that you will now have a non-compiling project. The volume of compilation errors will obviously depend on the size of your project and its usage of the Play APIs. Attempts have been made wherever possible in supporting HMRC libraries to mitigate the effects of this.\n\nFor frontends, the volume of compilation errors introduced as a result of upgrading to Play 2.5 is liable to be pretty high. However, the majority of these will probably be the result of changes to the i18n API. Any use of `@Messages` in Twirl templates now require an implicit `play.api.i18n.Messages` instance. This messages API encapsulates access to Lang, so you might also be able to remove a lot of implicit references to Lang which are no longer required.\n\nFor a blank frontend created using init-service, the following Twirl templates needed to have an implicit messages parameter added:\n\n1. govuk_wrapper.scala.html\n2. main_template.scala.html\n3. error_template.scala.html\n4. hello_world.scala.html\n\nAs a result of introducing the implicit `Messages` parameter to the Twirl templates, you get a cascade of compilation failures as wherever they are referenced now also needs a reference to `Messages`. Obviously, Play recommend that you use DI to obtain this reference. However, if you are unwilling (e.g. because you do not want to migrate all your object-based controllers yet) or unable (e.g. because you cannot dependency-inject an application global) to use DI, there is a workaround.\n\nA. `import play.api.i18n.Messages.Implicits._`\nB. `import play.api.Play.current` (deprecated, but still works)\nC. Explicitly pass the implicit messages parameter where required using `applicationMessages`, which is provided by `play.api.i18n.Messages.Implicits`\n\nThe first place we need to use this workaround is for the error handler methods in `frontendGlobal`. You will also almost certainly need to use this workaround in your controllers (or migrate them to use DI).\n\nAdditionally, if you have filters, they now require you to provide an Akka Materializer. The play-filters library provides a MicroserviceFilterSupport mixin trait which does this for you. Simply mix it in to your filter object.\n\nFinally, support for `onLoadConfig` has been entirely removed from `GlobalSettings` in Play 2.5. Fortunately, we weren't actually using it but, if your specific frontend does, then you will need to find an alternative technique to achieve your aim in doing so. See https://www.playframework.com/documentation/2.5.x/GlobalSettings#Scala. More likely is that the init-service script will have placed a pointless override of `onLoadConfig` which is still sitting there unused and that now needs to be removed, if present, from your `frontendGlobal`.","distinct":true,"url":"https://api.github.com/repos/hmrc/example-play-25-frontend/commits/8642da46ae1e2b563f8b38ec9099c94eb5cb608b"},{"sha":"6bd9ac8c19ccf1c95469d65ad39dfad81e988132","author":{"name":"Christopher Townson","email":"1ab404878e46d892882bc722116d6f5877434cec@gmail.com"},"message":"Step 6: CRITICAL make Play use your GlobalSettings for request handling\n\nBy default, Play 2.5 no longer calls application lifecycle event methods in GlobalSettings, instead using DI-based components. However, they do provide an out-of-the-box HttpRequestHandler implementation that will simply delegate back to the corresponding lifecycle event method in your GlobalSettings. You MUST use this in order for a great deal of HMRC functionality (and metrics) to work properly:\n\n1. Add `play.http.requestHandler = \"play.api.http.GlobalSettingsHttpRequestHandler\"` to you conf/application.conf\n\nCogratulations! You have migrated your microservice to Play 2.5!","distinct":true,"url":"https://api.github.com/repos/hmrc/example-play-25-frontend/commits/6bd9ac8c19ccf1c95469d65ad39dfad81e988132"},{"sha":"d92fefe7e7f8e3aa84f2bcebb0c3e78182705443","author":{"name":"Christopher Townson","email":"1ab404878e46d892882bc722116d6f5877434cec@gmail.com"},"message":"Step 7: rename application-logger.xml to logback.xml\n\nPlay 2.5 now works with logback defaults. Consequently, the `application-logger.xml` console and file logger configuration which is provided for developer convenience is no longer applied. This won't have any functional impact on your app or its logging in a deployment environment but you may want the developer logging back.\n\n1. Rename `conf/application-logger.xml` to `conf/logback.xml`","distinct":true,"url":"https://api.github.com/repos/hmrc/example-play-25-frontend/commits/d92fefe7e7f8e3aa84f2bcebb0c3e78182705443"}]}
{"actor":{"display_login":"iteratoruk"}}