[GRADLE-1765] Gradle Tooling API not obeying Gradle Wrapper settings for subprojects Created: 25/Aug/11  Updated: 04/Jan/13  Resolved: 11/Dec/11

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 1.0-milestone-7

Type: Bug
Reporter: Kris De Volder Assignee: Unassigned
Resolution: Fixed Votes: 3


 Description   

When the Gradle Tooling API is invoked directly via a subproject it doesn't obey the gradle wrapper version from the parent project.

I discovered this while experimenting with http://static.springsource.org/spring-security/site/source.html

This project seems to the same bug as spring-integration: http://issues.gradle.org/browse/GRADLE-1701

However, its gradle wrapper specifies to use M3 (which means that it should not hit the bug).

It indeed does not hit the bug when the model gets built from the root project. However, when requesting a model build from one of the subprojects (such as will happen in STS if you perform a "refresh dependencies" operation on a specific subproject) then it seems to fall back to using the tooling api's default version rather than the wrapper default. In this case it will hit the bug (and the error message indicates M4 was being used).

In my mind this is a rather serious bug because it causes very unpredictable behavior for multi-project builds in the IDE, where it somewhat randomly varies which gradle version you end up using depending on things such as project build order etc.



 Comments   
Comment by Kris De Volder [ 24/Oct/11 ]

Task execution is also affected:
https://issuetracker.springsource.com/browse/STS-2201

In some cases this means it is impossible to execute any tasks on subprojects in STS. For example, a project like spring-security which has a build that only works with M3 is severely affected.

When trying to execute any task on a subproject, the api will ignore the wrapper settings, switch to using M4 and crash.

Generated at Wed Jun 30 12:03:46 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.