Fix a compile error that happens on Eclipse import only #778

wants to merge 1 commit into


None yet

3 participants

kdvolder commented Apr 2, 2013

The precise error is (copy pasted from Eclipse problems view):

The method applySystemFileSeparator(String) is undefined for the type TestUtils /spring-integration-file/src/test/java/org/springframework/integration/file line 124 Java Problem

This error does not happen when building / running tests with Gradle on the commandline.
I believe this is because Gradle separates 'test' and 'main' source sets but in Eclipse a project can only have a single classpath. Thus when importing to Eclipse the test and main source folders are merged together for the Eclipse compiler.

Because of this the two copies of TestUtils that exist in the code end up in the same eclipse classpath and unfortunately the TestUtils reference is resolved to the wrong one in this case.

As I figured the intention is for the two TestUtils classes to be the same I 'fixed' the problem by copying the implementation of the missing method from the other TestUtils class.

ghillert commented Apr 4, 2013

How do you import the project into Eclipse? Do you import as Gradle project or create the Eclipse meta data from the command line and then import? I never experienced problems in that regard. I import using the STS Gradle support (On MacOS).

kdvolder commented Apr 4, 2013

I am importing with the STS Gradle Support on Linux. Actually importing spring-integration with Gradle tooling is one of my gradle tooling regression tests.

My guess is that whether or not you get the error may depend on some not very well specified things, such as the order in which things end up in the classpath. As there are two copies of the type that end up in the classpath, I think you have a 50/50 chance of getting the correct one.

The behavior does seem deterministic. I.e. as you never see the problem, but I always see it.

I am guessing this may be dependent on what order certain file listings are returned by the OS or some other platform dependent ordering of things. The order may deterministic but platform dependent.

kdvolder commented Apr 4, 2013

BTW: I was assuming you must have a good reason for copying the type. Otherwise I would have tried to fix it by removing the copy in the 'test' source set and try to have everyone just use the one from main source set.


FYI; I just hit the same problem (importing as gradle project with Linux); it may be a bug in the import - the ...file project really shouldn't have visibility to the src/test folder in core. Doesn't happen when using ./gradlew cleanEclipse eclipse form the command line.

I will merge this for now, but we should consider a better solution to having this code replicated in both places.


Thanks for this.

Merged; you will need to git reset --hard your master branch before merging.

In future, please consider using a topic branch; it makes merging back the master easier.

@garyrussell garyrussell closed this May 1, 2013
kdvolder commented May 1, 2013

In future, please consider using a topic branch; it makes merging back the master easier.

Sure. Apologies. I didn't realize it made a difference to the merge process whether I use master or another named branch.

the ...file project really shouldn't have visibility to the src/test folder in core.

It is a limitation of Eclipse. You can't have multiple classpaths for a single project. So anything that needs to be visible to src/main must also be made visible to src/test or the other way around.

This is evidently not correct, but it is how Gradle maps classpaths into Eclipse given its limitations.

My guess about why the error doesn't happen with ./gradlew eclipse is that it is dependent on the order of the classpath entries which ever one is first on the classpath wins.

You could probably get the same behavior with the tools if you import the projects with 'dependency management' disabled. In this the tools will use the 'eclipse' task to generate metadata rather than query the Gradle tooling API. That would make the behavior more likely to be the same.

Even so, the order of classpath entries, I think, is not specified and may depend on things like OS and the order Java File APIs return entries in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment