Add support for Play 2.4

[mkurz]

I squashed the commits from @vmouta from #249 into one nice, single commit. Then I added lots of enhancements and cleaned up the code. Unfortunately I also squashed all the work I have done into vmouta's commit, but I don't really care as I don't have time to extract my changes out of his commit. I am sure there is some git magic to do so but I don't want to waste time.

This PR does not use dependency injection yet, it still relies on a play.plugins file. It's ok for now, but for Play 3.0 this has to be addressed, as Plugins will be removed in favor of Modules written with DI.

The release notes for deadbolt can be found here and here.

@joscha Could you please review this PR and if you are fine with it merge and release a snapshot so people can test?

[vmouta]

I would suggest also to update to bootstrap 3.3.4.

[mkurz]

@joscha Could you have a look at Travis build? Also my last commit can be reverted as soon there are stable versions of easymail and deadbolt.

[mkurz]

@joscha If you need any help or infos let my know :smile:

[Enalmada]

I could be wrong but when converting my java project to 2.4, I seem to remember changing ebean associations to something like this to get it to compile: Ebean.saveManyToManyAssociations(user, "roles")

Though now I wish I just tried commenting it out.

[joscha]

it seems as if the build breaks because of the aggregation of the test-app and play authenticate. This one does not seem to work any more:

lazy val playAuthenticate = (project in file("modules/play-authenticate")).enablePlugins(PlayJava)

lazy val root = (project in file("."))
  // ...
  .dependsOn(playAuthenticate)
  .aggregate(playAuthenticate)

I read the sbt docs but it appears to be correct. Any ideas?

[mkurz]

No idea. For developing local on my machine I published a snapshot into my local ivy repos and then commented these lines out and instead added

  "com.feth"      %% "play-authenticate" % "0.7.0-SNAPSHOT",

into appDependencies.

[mkurz]

This approach of course doesn't work for us as there is no SNAPSHOT available yet.

Also, I predict that when Travis wants to run the tests for the play-authenticate-usage and the play-authenticate-simple-oauth sample app it will fail because of the same reason (both depend on a 0.7.0-SNAPSHOT in its appDependencies, but there is no SNAPSHOT published yet.

[mkurz]

Or wait - am I wrong? Because Travis of course will publish a SNAPSHOT into its local repos too at first, so my approach from https://github.com/joscha/play-authenticate/pull/258#issuecomment-110825266 should work, shouldn't it?

[mkurz]

I added a commit - waiting for Travis. I can remove the commit if it's a bad idea/approach.

[joscha]

travis published locally, so that is not a problem. your commit should make the test-app initialise, but the tests should fail, because play-authenticate is missing.

[joscha]

@mkurz does the sample app work for you? I keep on getting:

[IllegalStateException: JSR-303 validated property 'repeatPassword' does not have a corresponding accessor for data binding - check your DataBinder's configuration (bean property versus direct field access)]

when registering via the password provider.

[mkurz]

Both worked for me. Which one do you mean? I can try again.

[mkurz]

I don't understand why Travis is failing. Why does it not find /home/travis/.ivy2/local/com.feth/play-easymail_2.11/0.7.0-SNAPSHOT/ after publish-local has run before? Why is it working on my machine then?

[mkurz]

Man, I am stupid. It couldn't find play-easymail (not play-authenticate). I should buy a stronger pair of glasses...

[mkurz]

@joscha About the samples apps, make sure you deleted all your target, bin folders, etc. so you start from clean. When I upgraded apps to Play 2.4 sometimes there was something cached that didn't make it work.

[mkurz]

@joscha Both samples apps work fine for me...

[mkurz]

@joscha Build is green! :tada: I did some cleanup in the last commits. Any chance for a (snapshot) release today?

[joscha]

hmm - @mkurz - now that the aggregation and dependency is gone, that means it is using the dependency from the repository - so basically the tests don't run against the code that was checked in - I have been trying to fix this the last few hours, but didn't have any luck. Do you have an idea if the symlinks are the problem?

[mkurz]

@joscha I don't really know. I don't have very deep knowledge of sbt. I would have to dig into and try...

[mkurz]

Is there any difference in writing

(project in file("modules/play-authenticate"))

or

project.in(file("modules/play-authenticate"))

?

Also what about instead using symlinks using this (don't know hoch much ../ are really necassary):

file("../../play-authenticate")

?

[vmouta]

Saw some people using the ./ - probably it doesn’t make any diference but not in condition to try now. (project in file("./modules/play-authenticate"))

On 10 Jun 2015, at 21:46, Matthias Kurz notifications@github.com wrote:

Is there any difference in writing

(project in file("modules/play-authenticate")) or

project.in(file("modules/play-authenticate")) ?

Also what about instead using symlinks using this (don't know hoch much ../ are really necassary):

file("../../play-authenticate") ?

— Reply to this email directly or view it on GitHub https://github.com/joscha/play-authenticate/pull/258#issuecomment-110889879.

[joscha]

@mkurz they are equivalent according to the manual. Using ../ is not possible as you can not leave the root project's base folder unfortunately. I also tried copying the code into the modules folder just to try, but it didn't seem to change much.

[joscha]

figured it out I think. Will create new PR and try to generate a snapshot...

[mkurz]

Nice!

[joscha]

see #259.

[mkurz]

Closing in favor of #259