The tooling API sometimes does or does not return buildSrc as a project


(Kris De Volder) #1

The tooling API sometimes returns buildSrc as a project and in other cases it does not. To the chagrin of some users who find this illogical / inconsistent.

A bug has been reported agains STS here:

https://issuetracker.springsource.com/browse/STS-3660

See that issue for details.

I could implement a workaround in STS to ignore buildSrc when returned by tooling API but I feel this is really a problem with the tooling API implementation rather than the tooling so it should be fixed ‘at source’.

Is that reasonable? Or is there in fact a good reason why the buildSrc project is returned in some cases whereas its not in others?

Kris


(Radim Kubacki) #2

I haven’t tried it yet but if there is such inconsistency then I think we should fix it and either always return buildSrc as subproject if it is present or be silent about it (and then I can imagine someone will ask for a method to access it because it is a project).

There is also a discussion about forcing user to import this project. Here it seems to me strange to make this import mandatory just because we know that this is a special purpose project. I’d even say that it can have completely different behavior and can likely cause troubles to resulting project.

I may also need to check how IntelliJ treats this and then we can discuss how to proceed: a) consistently return it if present and deal with it in IDE plugins, b) expose it through a different API and again enhance plugins to cope with that, c) do something else.

-Raidm


(Attila Kelemen) #3

I have never experienced such issue, no matter if buildSrc had or had no build.gradle. Can we rule out user error (reading the STS bug report)? For example, consider the following scenario: Assume settings.gradle is implemented so that it inculdes each folder if it contains a build.gradle. In this case, adding build.gradle to buildSrc will list buildSrc as a subproject.


(Kris De Volder) #4

There is also a discussion about forcing user to import this project. Here it seems to me strange to make this import mandatory just because we know that this is a special purpose project. I’d even say that it can have completely different behavior and can likely cause troubles to resulting project.

Let me clarify that point.

Currently, according to the user who reported the STS bug, if ‘buildSrc’ project is returned it is also treated as a dependency of the containing project (I have not verified this myself)

Because of this, STS will force the project to be imported because the import wizard verifies that if a project is imported, dependent projects must also be imported. In general this rule makes sense because not importing dependent projects will result in compilation errors in the workspace.

If there is no requirement to import the buildSrc project it should perhaps not be treated as a dependency, (or perhaps it should be somehow flagged as a optional dependency if that’s possible)


(Kris De Volder) #5

Fair point. I will try to reproduce the problem myself and failing that ask the user for a demo project.


(Kris De Volder) #6

Tried to reproduce problem and was not able to. So maybe it is ‘user error’. Let’s wait on the user to provide more info either here or in the STS issue.


(mauromol) #7

Hi, I’m the reporter of the original issue. Attila Kelemen’s intuition was exact, I totally forgot about the fact that my settings.gradle dynamically adds projects to my multiproject once it finds a .gradle file in a root project subfolder. So, filtering out buildSrc from this detection did the trick. Sorry for wasting your time!


(Radim Kubacki) #8

OK. Good to know that this is solved. As a follow-up if will check how imported buildSrc affects resulting IDE projects at some point and can ping Kris if there is something what seems worth updating.