Play 2.4 support

[JamesMcIntosh]

When trying to run raygun4java with play 2.4 the following error occurs.

I see that there is a pull request waiting review it which addresses this problem.

https://github.com/MindscapeHQ/raygun4java/pull/44

Could I suggest that you have branches for the different play versions if you need to support them?

java.lang.IncompatibleClassChangeError: Found class play.api.mvc.Headers, but interface was expected at com.mindscapehq.raygun4java.play2.RaygunPlayScalaRequestMessage.<init>(RaygunPlayScalaRequestMessage.java:19) at com.mindscapehq.raygun4java.play2.RaygunPlayMessageBuilder.SetRequestDetails(RaygunPlayMessageBuilder.java:37) at com.mindscapehq.raygun4java.play2.RaygunPlayClient.BuildServletMessage(RaygunPlayClient.java:115) at com.mindscapehq.raygun4java.play2.RaygunPlayClient.SendAsync(RaygunPlayClient.java:77)

[JamesMcIntosh]

Looks like the pull request doesn't fix the problem when using maven to build the project as the pom.xml has not been updated. I'll make a new pull request which should fix this.

[JamesMcIntosh]

I've made the new pull request https://github.com/MindscapeHQ/raygun4java/pull/46

[fundead]

Hi James,

Unfortunately we've found separate branches not scaleable as it introduces a maintenance overhead and a collision in the Maven dependency. Our approach when frameworks introduce breaking changes is to provide separate dependencies much like the current ones (as in Raygun4Net which has support for the many flavours of .NET).

Releasing this is not quite as trivial as merging in these PRs, however they will form the base of a new dependency. Following testing and QA this will enable both Play <= 2.3 and 2.4+ to be fully supported side by side, with HTTP data for both. We'll get one of the team to implement this for you next week.

Regards,

Callum Raygun Limited

[JamesMcIntosh]

I'm not sure how your build process goes but a couple of ways you could tackle it could be:

Branches

I think that the API for Play is stable between 2.x releases so you should only have to change the pom.xml files between branches. This way you would not have to repeat the code in two places. I haven't tried compiling against 2.5 or 2.6 RC though so that may not be the case.

When releasing it's easy not to collide the maven dependency if you have a different artefact id in the pom files on each branch.

If you pull the play support out into a different top level project then you wouldn't have to port the changes to the core module between branches so maintenance should be less.

Folders

Just looking at the project again your suggestion to structure it like the .NET project by having separate module directories for playprovider 2.3/2.4/2.5 etc. would work well but requires a second copy of the exact same code (assuming not code changes are necessary between versions).

You can I believe override the src folder for the compile plugin in the pom.xml config to share the src folder for the different versions.

Thanks for considering the pull request and taking the project forward. James

[TheRealAgentK]

Closing this because it's quite old and had been superseded already.

I think the points of building for different versions of Play are valid and interesting though and we might take that into consideration at some stage.