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

Duplicated by

Bug - A problem which impairs or prevents the functions of the product. GRADLE-1529 Eclipse model built by the tooling api for a project which does not use the eclipse plugin lists tasks which cannot be executed

  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
Kris De Volder added a comment -

Attaching a sample project

Show
Kris De Volder added a comment - Attaching a sample project
Hide
Permalink
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
Permalink
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
Permalink
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
Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: