Remove test dependencies from runtime classpath

[donat]

Context

The Buildship runtime classpath provided for Eclipse is different from the one used in Gradle. This leads to problematic classpath differences when the user executes a Java application from the IDE and via a Gradle build. It makes Spring Boot application development with STS and Buildship painful.

Original post: https://bugs.eclipse.org/bugs/show_bug.cgi?id=482315

Overview

Buildship should read the runtime classpath from the Gradle build and use it in Buildship.

In Gradle, all source folders and classpath entries should be marked with classpath attributes describing which source sets they belong.

In Eclipse the default JDT runtime classpath calculation should be overridden removing all elements from the classpath that don't belong to the same source set where the launched class is declared.

Implementation in Gradle

The eclipse plugin should define the following classpath attributes:

• source folders: <attribute name="gradle_source_sets" value="main,test"/>
• external dependencies: <attribute name="gradle_source_sets" value="main,test"/>

The source folder attribute is easy because the SourceFoldersCreator instantiates source folders directly from SourceSets.

To calculate the attribute for the external dependencies we have to collect the runtime classpath entries for all source sets. Then, EclipseDependenciesCreator should look up which source sets an external dependency belong and add this info as a classpath attribute.

Implementation in Buildship

Step 1 - Adjust GradleClasspathContainerRuntimeClasspathEntryResolver

The classpath container should automatically pick up the new classpath attributes from Gradle.

The classpath entry resolver should only add an external dependency to the runtime classpath if the target source folder from the run configuration and dependency have a common source folder. If the source folder can't be determined (e.g. no run configuration is provided) then no such filtering is needed.

Step 2 - Provide custom JDT classpath provider

Along with external dependencies, Buildship should filter source folders that don't belong to the source set from where a JDT execution is launched. It can be done by contributing a custom runtime classpath provider via the org.eclipse.jdt.launching.classpathProviders extension point. Here's the required interface to implement:

public interface IRuntimeClasspathProvider {
    IRuntimeClasspathEntry[] computeUnresolvedClasspath(ILaunchConfiguration);
    IRuntimeClasspathEntry[] resolveClasspath(IRuntimeClasspathEntry[], ILaunchConfiguration);
}

We should implement this extension point such that an entry is not added to the runtime classpath if it's not part of the current source set. The existing GradleClasspathContainerRuntimeClasspathEntryResolver class should be merged with this code.

We should inject this custom provider via a launch configuration listener. The listener should check all launch configuration creation and if the target project is a Buildship project, then it should change the classpath provider to our implementation. Besides, if the Buildship nature is added/removed to a project, the classpath provider should be automatically updated accordingly.

Since there are a couple of different JDT launch types exist (java, junit, maybe testng) we should make sure that our custom runtime classpath injection supports all of them.

[Raj-Kishan]

Encountered this problem while using Spring Tool Suite. Unable to run spring-boot applications inside the IDE if i have a dependency testCompile('org.flywaydb:flyway-core') . Is there any fixes planned in future?

[oehme]

We currently don't have the capacity to start this, but seeing that it is the highest voted issue, we will schedule it once we finish some of the other big items we currently have in flight.

This will need some more design though, because we can't just hardcode main/test somewhere in Buildship. I can imagine marking each source folder and each dependency with their corresponding SourceSet and then deciding which dependencies to include based on which class is launched.

This is simple for "Launch as Java Application", because there you launch exactly one class. It gets tricky for "Launch JUnit Test", because you can tell Eclipse to launch all tests in the whole project and these might come from different SourceSets (e.g. test and integrationTest). I guess in that case the simplest solution is just to fall back to the current behavior. That way we would at least improve the very common case of launching an application.

The nice thing about this solution is that it lines up with the proposed solution for "multiple compile classpaths" in the e4 incubator. So we could reuse their classpath attributes and get the dependency usage validation for free if the user has that plugin installed.

[kdvolder]

For what its worth... I like your proposed solution. I think it will be great as it will:

• solve the case where folks run a 'main' class (and the test deps should not be included)
• solve the cases where user only runs tests from a single source folder (e.g. only integration tests, or only unit tests)

It still won't fix the case where someone tries to run both integration and unit tests. But... well... yeah... that one is hard (is it even really fixable, you can't possibly run all those tests 'correctly' in a single classpath). Whatever the case may be. I'm glad you decided to try fix the 'easy cases', and you are even taking it a step further than just fixing the 'java main' case I had in mind. So... yeah... this sounds really good!

[evser]

I agree that this issue makes builds failed.

[mxab]

I we are facing this issue as well. Eventually this means you cannot use a src/main/java and src/test/java setup for spring applications
See this showcase https:/mxab/gradle-spring-demo

For now we just moved our tests into a separate project that depend on the real project

[donat]

A small announcement here. You'll see some improvements regarding this issue in the next minor release.

I already have a small prototype locally where the test dependencies are excluded from the runtime classpath when the main method is outside of the test sources.

[lukeu]

Can I test this by switching my wrapper to a recent nightly?

[donat]

Not yet, unfortunately. What you see on the screenshot is really just a prototype that we used for validating our approach how to solve the problem. We'll post an update here once we have something to try.

[donat]

Pull request extending the Eclipse model in Gradle: gradle/gradle#2943.

[donat]

To @lukeu and everyone who wants to give this feature a try: I've prepared a snapshot update site from the development branch containing this feature. Here's how you can use it.

1. Install the snapshot version from the following update site: http://download.eclipse.org/buildship/updates/e47/snapshots/2.x/2.1.3.v20170922-1430-s

2. Create (or import) a project with the latest Gradle snapshot (4.3-20170921000043+0000 or above).

3. When the import is finished, you should see new attributes in the .classpath file:

4. Execute a main() method. If it is defined in the main source set, then referencing a test class should result in a java.lang.NoClassDefFoundError.

[lukeu]

Great! I will give that a spin over the weekend. Quick question: will this also consider test resources? One of the issues we hit is that modules include a logback.xml file to tweak logging settings for their unit tests, but from Eclipse they interfere with logging in the main app.

[donat]

Thanks for trying it out! No, the current change separates binary dependencies only. As a next step, I'll look into removing the test resources from the main classpath. It's not that simple because Eclipse by default uses the same output folder for all source files.

[oehme]

We should change that on the Gradle side and set a different output folder for each sourceSet. E.g. bin/main, bin/test etc. That would fix other issues that users have reported too.

[donat]

I agree, ultimately that will be the solution. Nonetheless, I want to prototype the solution in Buildship first because it's faster and this way users can try it out faster (by modifying their classpath definition in the whenMerged block).

[donat]

@lukeu Today I had time to continue on this story. I prototyped a custom classpath provider on the feature branch so that project resources from external source sets are excluded too. I updated the update site URL in my previous comment.

Because I haven't changed anything in Gradle core, you have to 'manually' adjust the source folder locations in your build script. It should look like this.

apply plugin: 'eclipse'

eclipse {
    classpath {
        file {
           whenMerged { 
               entries.find { it.path == 'src/main/java' }.output = 'bin-main'
               entries.find { it.path == 'src/test/java' }.output = 'bin-test'
           }
        }
    }
}

Note, that you might have to manually delete the run configuration being used and the content of the default project output dir (<project_dir>/bin) to see the changes.

If it works well you should see something like this:

[lukeu]

OK I gave this a spin. Your minimal test works as described after creating a new Gradle project.

However I didn't have much joy with a full project import. I already tweak the Eclipse output to ensure that Eclipse builds use a different output from the Gradle and Maven command-line builds. (We're still in transition). So I began with this:

subprojects {
  eclipse {
    classpath {
        defaultOutputDir = file("target/eclipse-classes")
        file {
            whenMerged {
                entries
                    .findAll { it.path.startsWith('src/test') }
                    .each { it.output = "target/eclipse-test-classes" }
                entries
                    .findAll { it.path.startsWith('src/it') }
                    .each { it.output = "target/eclipse-int-test-classes" }
            }
        }
    }
  }
}

I then tried changing defaultOutputDir to bin-main and src/test to use bin-test, but that didn't help. Was that the correct thing to do?

I found that the test directories from each module were still in the classpath. (Confirmed from the logging behaviour, and by Debug view > right-click java.exe > Properties.)

For reference our sourceSets are as follows:

sourceSets {
    main {
        output.classesDir = buildDir.toPath().resolve("classes")
        output.resourcesDir = buildDir.toPath().resolve("resources")
    }
    test {
        output.classesDir = buildDir.toPath().resolve("test-classes")
        output.resourcesDir = buildDir.toPath().resolve("test-resources")
    }
    intTest {
        compileClasspath += main.output + test.output
        runtimeClasspath += main.output + test.output
        java {
            srcDirs = [projectDir.toPath().resolve('src/it/java')]
        }
        resources {
            srcDirs = [projectDir.toPath().resolve('src/it/resources')]
        }
        output.classesDir = buildDir.toPath().resolve("int-test-classes")
        output.resourcesDir = buildDir.toPath().resolve("int-test-resources")
    }
}

Note, that you might have to manually delete the run configuration

Tip: it takes me a while to create a new run configuration (lots of settings and half a dozen environment vars). It seems to be sufficient to switch to the 'classpath' tab, and click "Restore Default Entries".

[donat]

@lukeu You don't have to create a run configuration manually. Let me explain the internals why I requested the deletion of the run configuration.

As you probably know already, Eclipse creates a run configuration for you when you launch a java main method. This config contains a hidden property called the classpath provider. My feature branch replaces the default classpath provider with a custom one when a configuration is created or changed. The implementation doesn't handle all use cases yet, so you might have to delete the existing run config to have the custom classpath provider injected.

The other thing I've seen is that even though you set custom output folders for your source folders and clean your projects, Eclipse might not clean up the default output directory. You might need to open the folder and delete the content manually.

[lukeu]

@donat
My testing went like this:

1. Created a fresh run-configuration in Eclipse Oxygen + Buildship from your update site, and configured the various options: main class, jvmargs and the env. vars required to run our product
2. Possibly afterwards, I switched the Gradle wrapper to 4.3-20170921000043+0000
3. Tried it first with my default directory names
4. Updated build.gradle to use your directory names.
5. On the command-line: found & deleted all target & bin dirs. Executed a gradle target to generate source-code
6. Right-click > Gradle > Refresh to pick up generated-source-code directories and the new output directory names
7. Used my "Restore Default Entries" trick in an attempt to avoid doing (1.) again

Do you think any of this was problematic (e.g. doing 2 after 1, or 7) and needs to be done again differently?

[donat]

I then tried changing defaultOutputDir to bin-main and src/test to use bin-test, but that didn't help. Was that the correct thing to do?

It doesn't really matter what is the default output dir until it's different from the other source dir's output.

Your steps in the previous comment seem fine to me. I don't completely understand what does step 7 do. In any case, I'll try to recreate your use case and see where Buildship fails.

[donat]

Feature announced in the milestone release: https://discuss.gradle.org/t/buildship-2-2-milestone-is-now-available/24551

[donat]

@Raj-Kishan @kdvolder @evser @mxab @lukeu and @everyone stumbling upon this issue:
Could you please give the latest milestone a go? To do that, just import a project with the latest Gradle 4.4 snapshot, and execute a Java application/JUnit test.

[mxab]

@donat I tried my showcase project it with the latest milesone in oxygen

The bean defined in the test config still seems to end up in the main classpath.

Maybe this is actually beyond the scope of this bug as it does not come from a dependency but the test source

[oehme]

Sources should also be filtered out. Are you using the latest Gradle 4.4 snapshot?

[mxab]

@oehme you are right! works with 4.4-20171102235952+0000 , sorry overread the snaspshot part.
great, I'll see if I can rearrange our real project again.

[lukeu]

OK I have:

• Upgraded Eclipse, & Buildship & troubleshooted all that.
• mvn clean and delete all the m2e projects (which I'm still using out of necessity)
• ./gradlew cleanEclipse (just out of paranoia)
• I found I had to execute our ./gradlew generateSources pre-build step in gradle 4.1 as it breaks in later versions (I found it regresses with Gradle 4.2. It fails to delete a file which is "in use", but it is only held by the gradle daemon itself.)
• Switched the wrapper to the latest nightly (4.4-20171103235949+0000) before Importing as Gradle Projects
• Reconstructed a launch configuration from scratch to be on the safe side

And... no joy unfortunately. The (customised) test output dirs are still present on the classpath:

-classpath C:\bin\dev\java\jdk1.8.0_121\jre\lib\resources.jar;
C:\bin\dev\java\jdk1.8.0_121\jre\lib\rt.jar;
...
C:\bin\dev\java\jdk1.8.0_121\jre\lib\ext\zipfs.jar;
C:\workspace\my-app\main\bin\main;
C:\workspace\my-app\module-a\bin\main;
C:\workspace\my-app\module-a\target\eclipse-test-classes;
C:\workspace\my-app\module-a\target\eclipse-int-test-classes;
\module-a\target\eclipse-classes;
C:\workspace\my-app\module-b\bin\main;
C:\workspace\my-app\module-b\target\eclipse-test-classes;
C:\workspace\my-app\module-b\target\eclipse-int-test-classes;
\module-b\target\eclipse-classes;
...

(Refer back to my comment on 24 Sep for the relevant parts of our build.gradle files.)

The file that should configure logging is in module-a so as a workaround I tried editing the launch configuration to explicitly put that first in the classpath. Unfortunately it doesn't help because it still picks up a test resource first from the same module:

module-a/src/test/resources/logback-test.xml

And uses that in preference to the desired:

module-a/src/main/resources/logback.xml

[donat]

@lukeu I have a couple of ideas what might have gone wrong. But first, a smaller thin that might be related. The latest eclipse plugin uses separate output locations for the source folders, so this bit should not be necessary for your project:

 entries
     .findAll { it.path.startsWith('src/it') }
     .each { it.output = "target/eclipse-int-test-classes" }

Buildship falls back to the original runtime classpath implementation if an old Gradle version is used for the project import or if one of the target source folders doesn't define dependency scopes. It's a bit tricky debug this because the UI hides some of the classpath information, but if you execute ./gradlew cleanEclipse eclipse and open the .classpath file, you should see something like this (note that normally you should not call the eclipse task when using Buildship because they are mutually exclusive):

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry path="bin/default" kind="output"/>
    <classpathentry output="bin/main" kind="src" path="src/main/java">
        <attributes>
            <attribute name="gradle_scope" value="main"/>
            <attribute name="gradle_used_by_scope" value="main,test"/>
        </attributes>
    </classpathentry>
    <classpathentry output="bin/test" kind="src" path="src/test/java">
        <attributes>
            <attribute name="gradle_scope" value="test"/>
            <attribute name="gradle_used_by_scope" value="test"/>
        </attributes>
    </classpathentry>
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8/"/>
    <classpathentry sourcepath="/Users/donat/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-math3/3.6.1/8fab23986ea8886af34818daf32a718e81dc98ba/commons-math3-3.6.1-sources.jar" kind="lib" path="/Users/donat/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-math3/3.6.1/e4ba98f1d4b3c80ec46392f25e094a6a2e58fcbf/commons-math3-3.6.1.jar">
        <attributes>
            <attribute name="gradle_used_by_scope" value="main,test"/>
        </attributes>
    </classpathentry>
    <classpathentry sourcepath="/Users/donat/.gradle/caches/modules-2/files-2.1/com.google.guava/guava/21.0/b9ed26b8c23fe7cd3e6b463b34e54e5c6d9536d5/guava-21.0-sources.jar" kind="lib" path="/Users/donat/.gradle/caches/modules-2/files-2.1/com.google.guava/guava/21.0/3a3d111be1be1b745edfa7d91678a12d7ed38709/guava-21.0.jar">
        <attributes>
            <attribute name="gradle_used_by_scope" value="main,test"/>
        </attributes>
    </classpathentry>
    <classpathentry sourcepath="/Users/donat/.gradle/caches/modules-2/files-2.1/junit/junit/4.12/a6c32b40bf3d76eca54e3c601e5d1470c86fcdfa/junit-4.12-sources.jar" kind="lib" path="/Users/donat/.gradle/caches/modules-2/files-2.1/junit/junit/4.12/2973d150c0dc1fefe998f834810d68f278ea58ec/junit-4.12.jar">
        <attributes>
            <attribute name="gradle_used_by_scope" value="test"/>
        </attributes>
    </classpathentry>
    <classpathentry sourcepath="/Users/donat/.gradle/caches/modules-2/files-2.1/org.hamcrest/hamcrest-core/1.3/1dc37250fbc78e23a65a67fbbaf71d2e9cbc3c0b/hamcrest-core-1.3-sources.jar" kind="lib" path="/Users/donat/.gradle/caches/modules-2/files-2.1/org.hamcrest/hamcrest-core/1.3/42a25dc3219429f0e5d060061f71acb49bf010a0/hamcrest-core-1.3.jar">
        <attributes>
            <attribute name="gradle_used_by_scope" value="test"/>
        </attributes>
    </classpathentry>
</classpath>

Buildship expects a gradle_scope and a gradle_used_by_scope attribute for each source folder and a gradle_used_by_scope for each jar dependency.

As of the run configurations, Buildship supports 2 types at the moment: java launches and JUnit tests. If you save the launch configuration to the disk (run configuration dialog -> common tab), you should see the following parameter in the file:

<stringAttribute key="org.eclipse.jdt.launching.CLASSPATH_PROVIDER" value="org.eclipse.buildship.core.classpathprovider"/>

[lukeu]

Szia @donat!

Thanks for the tips. My .classpath file looks pretty similar to your sample, even with our directory customisations. I've removed them all from build.gradle before further testing anyway.

It seems the issue is that the runtime classpath is only filtered to main for the main application directory. All modules included transiently have main, test and intTest still. I may have simplified some details out of the classpath in my previous comment. Here it is again with the default output dirs:

C:\bin\dev\java\jdk1.8.0_121\jre\lib\ext\zipfs.jar
...
C:\workspace\my-app\application\loader\bin\main
...
C:\workspace\my-app\module-a\bin\main
C:\workspace\my-app\module-a\bin\test
C:\workspace\my-app\module-a\bin\intTest
\module-a\bin\default
C:\workspace\my-app\module-b\bin\main
C:\workspace\my-app\module-b\bin\test
C:\workspace\my-app\module-b\bin\intTest
\module-b\bin\default

Note how the main application (at the top, after the JDK) is not a parent of the other modules in the filesystem. I don't suppose that is significant?

Buildship falls back to the original runtime classpath implementation if an old Gradle version is used for the project import or if one of the target source folders doesn't define dependency scopes.

We also have empty parent directories that group some sub-modules together, which are imported with .classpath files also. However they have no source folders at all. Could that possibly trigger this fallback behaviour?

[donat]

@lukeu

Note how the main application (at the top, after the JDK) is not a parent of the other modules in the filesystem. I don't suppose that is significant?

It should not matter.

We also have empty parent directories that group some sub-modules together, which are imported with .classpath files also. However they have no source folders at all. Could that possibly trigger this fallback behaviour?

I might miss something here. So you have some projects in the workspace that you don't import with the Import Gradle project wizard?

At this point, I think it would be nice if you could just create a sample project exhibiting the problem. That way I'd be able to analyze the problem much faster.

[BetterWork4BetterWorld]

Hello, I still have this problem too. And for me it is a blocking issue. I use EmbeddedMongo database for test, and because this dependency is in the runtime, I can't launch my non-test classes without launching AND use this embedded databse which of course does not fit for production environnement. Can you help ?

I precise that I just upgrade to gradle 4.6

[donat]

@BetterWork4BetterWorld The latest Buildship should work for you. Just make sure you use Buildship 2.2+ and your project is actually imported with the proper Gradle version.

[lukeu]

@donat,

At this point, I think it would be nice if you could just create a sample project exhibiting the problem. That way I'd be able to analyze the problem much faster.

I've now taken a 3rd crack at this (a couple of days) attacking it from both ends:

• building up a test with 4-5 projects and copying over any bits from the production build which look like they could possibly be related
• chopping down the production build definitions as much as I can without breaking it

No joy :-( The minimal example still works as expected, and bin/test is still on the classpath of the production builds.

There may be a small clue from your suggestion to look for this:

<stringAttribute key="org.eclipse.jdt.launching.CLASSPATH_PROVIDER" value="org.eclipse.buildship.core.classpathprovider"/>

If I delete that from the .launch file in my minimal test, then I see the same behaviour as in production. This makes me think more about what you said here:

Buildship falls back to the original runtime classpath implementation (...) or if one of the target source folders doesn't define dependency scopes.

I guess Buildship is "falling back" - but I'm at a loss as to why. Do you think it would be possible for me to debug Buildship to obtain some more clues? In anticipation I've started following the Oooph instructions to get set up. Any pointers where to stick a breakpoint etc.?

(btw, would it be better to spin this out to a new issue - even if it turns out to be a non-issue? Or hold off until I have more concrete info)

[lukeu]

Huh, the key to making my minimal example fail was so simple in the end! Just run using JDK8 (I was previously using 9) and/or add:

sourceCompatibility = targetCompatibility = 1.8

Here is the minimal example: proj.zip. When proj-main is run, it prints:

Looking around...
 Yay
 Boo

Furthermore, if from the 'broken' state (after Gradle import) I then do:

./gradlew cleanEclipse eclipse
Standard refresh of the projects (F5)

Then the project runs as I would expect, without test resources on the CP. It prints:

Looking around...
 Yay

[lukeu]

I've had a bit of a dig around in the code. If you put a breakpoint on

GradleClasspathContainerRuntimeClasspathEntryResolver:90

then launching my test should catch the call to: JavaRuntime.resolveRuntimeClasspathEntry, which seems to be the point that the main/test directories of the the transient library proj-lib are introduced into the classpath.

A vague hunch - does something like what is done in GradleClasspathProvider.resolveOutputLocations need to be done here also? (Perhaps by moving or duplicating the logic of methods resolveClasspath, resolveOther, resolveProject into GradleClasspathContainerRuntimeClasspathEntryResolver ?)

[alienisty]

Hi All,
Since gradle 5.6 this problem popped up again.
The last gradle version that works correctly is 5.5.1.

[donat]

@alienisty Let's continue the conversation at #953.