Hello. I’m having an issue with the Eclipse plugin including test srcs when I run my main application in Eclipse.
I’ve set up a very simple project consisting of src/main/java/App.java src/main/resources/b_main.txt src/test/resources/b_test.txt
App.java:
public class App
{
public static void main( String[] args )
{
System.out.println( "Hello World!" );
System.out.println(App.class.getClass().getResource("/b_main.txt") != null);
System.out.println(App.class.getClass().getResource("/b_test.txt") != null);
}
}
build.gradle:
apply plugin: 'java'
apply plugin: 'maven'
group = 'b'
version = '1.0-SNAPSHOT'
description = """"""
sourceCompatibility = 1.5
targetCompatibility = 1.5
repositories {
maven { url "http://repo.maven.apache.org/maven2" }
}
dependencies {
testCompile group: 'junit', name: 'junit', version:'3.8.1'
}
I import this project into Eclipse (File->Import, Gradle Project) and run App as a Java application.
Expected is
Hello World!
true
false
meaning it can see the resource in src/main/resources, but not the resource in src/test/resources
But what I actually get is
Hello World!
true
true
meaning it can see the test resources as well.
I’ve tried the same project using maven instead and it gets the expected result (test sources are excluded).
In our real application this is causing issues when we run it from Eclipse as the test sources override the main sources unexpectedly.
Is this a known issue? Is there a workaround?
Thanks, Mike
1 Like
It seems that you are using Eclipse plugin from https://github.com/spring-projects/eclipse-integration-gradle. You can check their bug tracker and/or forums (https://github.com/spring-projects/eclipse-integration-gradle#questions-and-bug-reports) whether this is known to them or not.
The problem here is Eclipse limitation expressed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=105372 JDT should support multiple classpaths per project. As a result your project will mix classes from main and test sourceSets (and possibly others). There is a possibility to improve the plugin to use classpath containers and generate launch configuration for execution that filters test roots. Or use a launch that delegates launch to Gradle. I believe IntelliJ is handling this more correctly (and NetBeans as well).
Thanks for the link. I’ll check in with that project.
Yeah, I think IntelliJ as test folders as a first class concept, so it’s probably a bit easier for their plugins to interact with it. It looks like it should be impossible in Eclipse due to the bug you linked to, but the maven plugin must do something under the hood.
I suppose they either use those classpath containers and build classpath on demand or somehow completely override project classpath in their launch type. Sorry, but I’ve never used Maven with Eclipse together. Again, it is possible to do it in Gradle suport it is just not there yet.
For those playing along at home, I ended up filing https://issuetracker.springsource.com/browse/STS-3882
It looks like similar issues related to WTP are blocked by http://issues.gradle.org/browse/GRADLE-1777
Actually the WTP issue is more Gradle’s fault: Gradle can generate .classpath files correctly for web projects but does not expose some of the information used to build them through tooling API and that’s why Eclipse plugin has a problem to process dependencies correctly. Again, we’re going to fix this eventually.
1 Like
Interesting. So that might only be a web project issue and not related to what I’m seeing with the test sources?
I’m curious how Intellij handles all this. Somehow their integration is getting the needed information (at least for the test srcs, no idea about the WTP stuff if that’s a separate issue).