Regression with application configuration discovery in test mode for sub-projects

[manuelbernhardt]

There appears to be some kind of regression in regards to plugin discovery during test, in Play 2.2-RC2

The situation I have is the following:

• a core sub-project has a conf/play.plugins file declaring a few plugins
• during test, the tests that live in the main sbt project run fine, i.e. the plugins are active
• during test, the tests that live in another module won't "see" the plugins declared in the other module (although it is a dependency)
  (the dependency is declared via dependsOn(core % "test->test;compile->compile") )

This was working in 2.1

[manuelbernhardt]

Interestingly enough, even when adding the plugin explicitly in FakeApplication it won't be found. It is as if the plugin was not in the classpath.

[manuelbernhardt]

The issue is present in 2.2.0 final as well, it seems

[manuelbernhardt]

Ok, I have a test application that demonstrates the issue: https://github.com/manuelbernhardt/issue-1695

My findings so far:

• plugins will be found correctly across modules when they are declared in the project itself
• there appears to be only one play.plugins file found when calling classloader.getResources("conf/play.plugins") here
• I don't think the SalatPlugin itself is at fault here because all it does is calling Application#plugins[T] which should be working

[manuelbernhardt]

More findings: this is not related to plugins, but to the application configuration discovery. It seems that prior to 2.2, a sub-project would "inherit" the configuration of the root play project, whilst now this doesn't happen any longer.

I was biased by the plugin lookup not working, and had overlooked that this particular plugin was in fact counting on having some configuration keys set in application.conf in order to be enabled. I updated the test application to reflect this behavior.

So in essence, one work-around for this regression is to instruct any tests located in sub-projects to behave as though their path was the one of the root project, such as e.g.:

"know about the salat plugin by explicitly setting the path to the root project" in new WithApplication(FakeApplication(path = new File("../../."))) {

  current.plugin[se.radley.plugin.salat.SalatPlugin] must beSome[se.radley.plugin.salat.SalatPlugin]

}

I updated the title of the issue to reflect the current state of findings.

[diwa-zz]

This is correct.
I have reported a similar problem - #1706

[alangalvino]

I have the same problem expliciting the plugin in FakeApplication. In play 2.1.3 this work.
E.x: FakeApplication(additionalConfiguration = testConfig, additionalPlugins = Seq("se.radley.plugin.salat.SalatPlugin"))

[eishay]

We have many sub-projects in our setup and this problem prevents us from migrating to 2.2. Any ideas when it would be resolved?

[kamatsuoka]

I'm wondering if this is an issue with sbt 0.13.

[eoliphan]

Not sure if this is related. I have a 'normal' play project without submodules. Since 2.2 my FakeApplication's aren't properly reading additionalConfiguration parameters I pass in. The test runs with the default applicaiton.conf settings and ignores the overrides.

[jroper]

I can confirm that there is a change in behaviour here. However, the old behaviour was most definitely a bug, and the new behaviour is correct.

If project A depends on project B, then it should be able to see resources from project B, not the other way around. So if you have a root project, and a sub module that the root project depends on, the root project should be able to see the classpath, and hence the application.conf from the sub module, but the sub module should not be able to see anything in the root project. For some reason, in Play 2.1, this wasn't the case, a sub module could see the application.conf from the root project, even if it didn't depend on that root project. This was a bug, and I'm not sure how or when, but I'm glad we fixed it.

In the sample project you provided, if you want both the core project and the root project to see the application.conf file, then it needs to be in a place where it will be on both of their classpaths. A simple place would be in the conf folder of the core project, instead of the conf folder of the root project.