Is this issue now "solved" by using proper dependencies and updated README?

Just based on the changes in the documentation, this error still occurs on Play 2.5 apps. I was able to correct this problem locally (haven't yet pushed this change to my fork yet) by updating the scala-jsonapi build.sbt to use an up to date play-json depdendency:

"com.typesafe.play" %% "play-json" % "2.5.4" % "provided",

However, I am not certain this is a backwards safe change, so it would lead me to think a major release increase would be needed.

Another solution I thought of, still not necessarily backwards compatible from 0.5.0 , would be to break up the project to be more modular. Instead of depending on scala-jsonapi, consumers could depend on play-scala-jsonapi or spray-scala-jsonapi. Each of these would in turn rely on scala-jsonapi for the bulk of the logic and really just provide wrappers around the actual JSON support. This could give two major improvements from my point of view:

1. It allows each support module to be upgraded independently based on changes in the external packages.
2. It allows for projects like play-scala-jsonapi to explicitly bring in Spray based packages that Play developers normally wouldn't think to include, fixing some of the documentation confusion as well.

Can you override the dependency by adding this to project/plugins.sbt in your project?

libraryDependencies += "com.typesafe.play" %% "play-json" % "2.5.4" % "provided"

I was also thinking of splitting this into more modular pieces, namely:

• scala-jsonapi-core - which would only have domain model definition and upstream transformation (reader and writer definition, etc.)
• scala-jsonapi-spray - which would use core underneath (ofc) and all necessary spray-json and spray.io (marshallers and unmarshallers) needed
• scala-jsonapi-play - same as above just for play
• scala-jsonapi-akkahttp - spray-json + akkahttp (un)marshallers

I tried to achieve this by having one repo (one project as it is now) and just using provided library dependencies. We could create submodules and package them into separate library while still maintaining one single repo. If you think separating the repos makes more sense I'd love to hear more about that.

Please give feedback.

Sorry for the very slow response. I was kinda dragged away from this.

@nehalium I tried adding the line to my plugins.sbt and just get a dependency issue (Unresolved dependency). Adding it directly to my build.sbt though did not throw any build errors, but also still did not solve the underlying problem.

Does it support Play framework 2.5 or not? I thought already supported :-)

@camuthig AFAIK, it is almost impossible to support multiple play-versions when depending on play libs, cause they have bc breaks between major versions (epoch.major.minor)...

swagger-play e.g. did a subtree split and is copying code for each play version. Or you could bump up major version for play 2.5 (depends on versioning scheme).

One solution, as @zmeda mentioned, would be to split play glue-code into a separate project and sync versioning with play-framework...

@frne fyi, Play's versioning scheme is epoch.major.minor -- Play 2.5 is binary incompatible with Play 2.4.

@wsargent Thx for clarification. That's what I meant...