Make GRADLE-1116 workaround more generic #183
Conversation
|
@rwinch Does this relate at all to https://jira.springsource.org/browse/SPR-9656? I notice that we both touched the same area of code. I really don't like the way that gradle tries to use the export option on the eclipse project classpath. I would prefer it if it just re-declared what it needed. The other day I found out all optional dependencies end up on the classpath unless you select Run Configurations... -> Classpath then select the user entry click edit and check "only include exported entries". |
|
Both this resolution and SPR-9656 update the Eclipse project models, but the issue and resolutions differ. This issue occurs when you use project('...').sourceSets.test.output (or other sourceSets output folders) which adds the output folders as a classpath entry. If gradle build has not been performed the folders will not exist. Secondly, Eclipse outputs the build to another folder so any updates would not be picked up. If you haven't already, you can check out the description on GRADLE-1116 for more details. |
Previously the workaround for GRADLE-1116 only worked for the merge-dist.gradle projects Now the workaround is more generic and fixes errors that have since been introduced when performing a fresh import into Eclipse.
# By Rob Winch # Via Rob Winch * gradle-1116: Make GRADLE-1116 workaround more generic # By Rob Winch * spring-test-mvc-classpath: Fix spring-test-mvc Eclipse classpath
Some errors have been introduced that occur when importing a project that has not yet been built that are due to GRADLE-1116. To see the issues you can run import a fresh clone or perform the following before importing.
Previously the workaround for GRADLE-1116 only worked for the
merge-dist.gradle projects
Now the workaround is more generic and fixes errors that have since
been introduced when performing a fresh import into Eclipse.