jTest.zip
|
Duplicate |
|||
| Duplicated by |
|
Eclipse model built by the tooling ap... | Resolved |
[GRADLE-1792] Tooling API always returns eclipse tasks even when eclipse plugin is not applied. Created: 12/Sep/11 Updated: 04/Jan/13 Resolved: 15/Sep/11 |
|
| Status: | Resolved |
| Project: | Gradle |
| Affects Version/s: | 1.0-milestone-3, 1.0-milestone-4 |
| Fix Version/s: | 1.0-milestone-4 |
| Type: | Bug | ||
| Reporter: | Kris De Volder | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 1 |
| Attachments: |
jTest.zip
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
To reproduce: Create a simple gradle project. A pretty much empty project with a pretty much empty buildscript will do. Tasks like 'cleanEclipse' and 'eclipse' will be among the returned results. However trying to run those tasks will fail with an error. |
| Comments |
| Comment by Kris De Volder [ 12/Sep/11 ] |
|
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: 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. |
| Comment by Kris De Volder [ 12/Sep/11 ] |
|
Attaching a sample project |
| Comment by Kris De Volder [ 13/Sep/11 ] |
|
This issue also block a proper implementation of |
| Comment by Adam Murdoch [ 15/Sep/11 ] |
|
This was fixed in 1.0-milestone-4: 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. |
| Comment by Kris De Volder [ 16/Sep/11 ] |
|
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. |