Add integrationTest.compileClasspath to idea's TEST scope

[jxblum]

Adding the integrationTest classpath configuration to the IDEA module's TEST scope will ensure that anyone building a Gradle-based project (using this Gradle plugin) with IJ will also properly have integrationTest dependencies declared. Otherwise, it is not possible to compile the project in IDEA.

Closes gh-33.

[jxblum]

By way of example, see Spring Session Issue #1163. This PR will fix that issue.

[rwinch]

Thanks for the report @jxblum Integration test dependencies work fine for me with Spring Security. I'm going to wait until the discussion on Spring Session gets resolved.

[jxblum]

Well, Spring Session will build fine with Eclipse (given Spring Build Conventions is complete in this regards, where IJ isn't), but I can assure you, they it will not build with IJ. If you just download IJ 2018.2.1, git clone Spring Session, and try to build it, it will fail as shown here.

This change in Spring Build Conventions will not affect IJ 2018.2, assuming IJ 2018.2 worked in the first place, which it doesn't (certainly not in all cases, i.e. import "Project from Existing Sources" use the Gradle project model, build).

And besides, if users are still on IJ 2017 or earlier, which I was (or according to @vpavic, even IJ < 2018.2, e.g. like 2018.1), then it will be a problem for those users anyway. We cannot expect users to always be using the latest version of their tooling (IJ, Eclipse or otherwise) to build our projects.

[rwinch]

From what I can see it works just fine. I did a fresh clone and ran the integration tests within samples/misc/hazelcast/integration-test without any compilation errors.

We also cannot be expected to work around other tools / libraries bugs (especially when they have fixed the issue in the latest versions).

With that said, I'd like to better understand why you are still having issues before deciding what to do with this issue.

[jxblum]

How is it a bug in the tooling?

Eclipse would not even work properly without this line.

Therefore, this line, that I added in this PR, is the IJ equivalent to Eclipse (line 121).

I don't understand how this possibly could work without manual intervention with IJ, such as excluding the compile or adding the Selenium dependencies as a global library.

Also, it does not count to build the Spring Session project with Gradle inside of IJ. I am talking about exclusively building with IJ and not kicking off any Spring Session build.gradle inside IJ (or in other words, building with Gradle IJ).

[rwinch]

I guess the question is why is this happening? Ever since the conventions plugin was created, I've never seen the problem in IntelliJ with integration tests.

[jxblum]

I have. In all versions of IJ that I have used. And there are only a handful of ways to work around this problem too.

[jxblum]

I used the following (this) as an example of how to fix this issue.

[jxblum]

See comment in Spring Session Issue #1163.

[rwinch]

Thanks for your patience while we tried to fully understand this issue @jxblum! Now that we figured out the problem, I have merged this into master.

[jxblum]

Thank you @rwinch. Much appreciated.

This will help me simplify my configuration of SSDG as well. Currently, to workaround this issue, based on my IDE setup, I have duplicated the integrationTestCompile config with a testCompile too, for example.

[rwinch]

@jxblum This was released as 0.0.18.RELEASE today http://repo.spring.io/plugins-release/io/spring/gradle/spring-build-conventions/0.0.18.RELEASE/

[jxblum]

@rwinch - Sweet! Very excited for this change as I will be able to simply my Gradle build files in SSDG. Thanks again!