Gradle
  1. Gradle
  2. GRADLE-1792

Tooling API always returns eclipse tasks even when eclipse plugin is not applied.

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Resolution: Duplicate
    • Affects Version/s: 1.0-milestone-3, 1.0-milestone-4
    • Fix Version/s: 1.0-milestone-4

      Description

      To reproduce:

      Create a simple gradle project. A pretty much empty project with a pretty much empty buildscript will do.
      Query the tooling API for the tasks on EclipseProject.

      Tasks like 'cleanEclipse' and 'eclipse' will be among the returned results.

      However trying to run those tasks will fail with an error.

        Issue Links

          Activity

          Hide
          Kris De Volder
          added a comment - - edited

          Note: this bug seems to have existed for a while. However it has only become important to me recently.

          The reason is a newly implemented STS feature:
          https://issuetracker.springsource.com/browse/STS-2091

          Unfortunately this feature can not be properly implemented without this bug getting fixed.

          The implementation I have now works only in theory. It intends to execute eclipse tasks only if the tasks actually exist on a project. But this bug makes it seem the tasks always exist, even if they do not.

          Consider a scenario where we have 20 odd projects most of which have the eclipse plugin applied and a few which do not. Such projects can not be imported reliably because of this bug. Attempting to execute eclipse tasks on all 20 projects will fail somewhere in the middle leaving tasks that should have been executed on the remaining projects unexecuted.

          Ignoring the error doesn't work either, because it doesn't change the fact that half of the projects that should have gotten eclipse files generated did not.

          Show
          Kris De Volder
          added a comment - - edited Note: this bug seems to have existed for a while. However it has only become important to me recently. The reason is a newly implemented STS feature: https://issuetracker.springsource.com/browse/STS-2091 Unfortunately this feature can not be properly implemented without this bug getting fixed. The implementation I have now works only in theory. It intends to execute eclipse tasks only if the tasks actually exist on a project. But this bug makes it seem the tasks always exist, even if they do not. Consider a scenario where we have 20 odd projects most of which have the eclipse plugin applied and a few which do not. Such projects can not be imported reliably because of this bug. Attempting to execute eclipse tasks on all 20 projects will fail somewhere in the middle leaving tasks that should have been executed on the remaining projects unexecuted. Ignoring the error doesn't work either, because it doesn't change the fact that half of the projects that should have gotten eclipse files generated did not.
          Hide
          Kris De Volder
          added a comment -

          Attaching a sample project

          Show
          Kris De Volder
          added a comment - Attaching a sample project
          Hide
          Kris De Volder
          added a comment -

          This issue also block a proper implementation of
          https://issuetracker.springsource.com/browse/STS-2085

          Show
          Kris De Volder
          added a comment - This issue also block a proper implementation of https://issuetracker.springsource.com/browse/STS-2085
          Hide
          Adam Murdoch
          added a comment -

          This was fixed in 1.0-milestone-4: GRADLE-1529

          You need to point the wrapper for your project at 1.0-milestone-4 or later. In your test project, you're declaring that the project requires 1.0-milestone-3, which does not have the fix.

          Show
          Adam Murdoch
          added a comment - This was fixed in 1.0-milestone-4: GRADLE-1529 You need to point the wrapper for your project at 1.0-milestone-4 or later. In your test project, you're declaring that the project requires 1.0-milestone-3, which does not have the fix.
          Hide
          Kris De Volder
          added a comment - - edited

          Sorry, I swear, that the test project didn't have a wrapper at all (despite the wrapper task in the build.gradle file, the task was not run, you'll see there's no wrapper properties in the project.

          My guess is that I probably had the version set to M3 in global workspace preferences without knowing it. It tends to get set to M3 because it is the only way I can work with some projects that don't have the wrapper, yet only work with M3.

          One thing though... I guess this is fixed in the gradle distro not the api, so we are still a little stuck until we can actually expect people to move away from using M3.

          In fact the test project I am using as a regression tests for functionality depending on running the eclipse tasks is spring-security and it only works with M3 so far.

          Is there any chance this could be fixed on the API side? I.e. fixed in a way that it would work with M3 if the API version is recent enough.

          Otherwise in practice https://issuetracker.springsource.com/browse/STS-2085 and https://issuetracker.springsource.com/browse/STS-2091 will still not work reliably for any real project I have available for testing this functionality.

          Show
          Kris De Volder
          added a comment - - edited Sorry, I swear, that the test project didn't have a wrapper at all (despite the wrapper task in the build.gradle file, the task was not run, you'll see there's no wrapper properties in the project. My guess is that I probably had the version set to M3 in global workspace preferences without knowing it. It tends to get set to M3 because it is the only way I can work with some projects that don't have the wrapper, yet only work with M3. One thing though... I guess this is fixed in the gradle distro not the api, so we are still a little stuck until we can actually expect people to move away from using M3. In fact the test project I am using as a regression tests for functionality depending on running the eclipse tasks is spring-security and it only works with M3 so far. Is there any chance this could be fixed on the API side? I.e. fixed in a way that it would work with M3 if the API version is recent enough. Otherwise in practice https://issuetracker.springsource.com/browse/STS-2085 and https://issuetracker.springsource.com/browse/STS-2091 will still not work reliably for any real project I have available for testing this functionality.

            People

            • Assignee:
              Unassigned
              Reporter:
              Kris De Volder
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: