This message was deleted.

Can you elaborate?

Sure. We have a single module depending on a library. In this library, we apply a precompiled script plugin. Everything is working fine. However, when developing, some team members are using the ‘includeBuild’ feature to include this library, so that they can always have the latest version, make code change in it without rebuilding it. With this configuration, the resolution of the precompiled script plugin in the included library fails with: ‘plugin is not in org.gradle namespace.

Does dependent project have

includeBuild

for both library and its included builds?

Not quite sure I get your question, but if the question is: does the project also includes the aforementioned library in its dependencies section in addition of the includeBuild directive, the answer is yes.

iirc it only changed if the version to be applied and the version on the classpath are exactly the same, though I might remember wrongly. I'm still not 100 % sure I fully get your situation. Can you mayb knit an MCVE?

Yup, on it.

Urgh, never use a project as subproject and separate build.

subproject-api

 is used as subproject of

subproject

and as subbuild of

main-project

. Instead include the

subproject

build from

main-project

and remove the settings script from

subproject-api

. Alternatively also use

includeBuild

from

subproject

to

subproject-api

. The

subproject

build defines

mavenLocal()

as plugin repository, the

subproject-api

build does not. So when you include

subproject-api

from

subproject

the plugin is available, but when you include it as subbuild from

main-project

, the plugin repository definition is missing as you don't have it in the settings script of

subproject-api

. You could of course also define the plugin repository in the

subproject-api

build and indeed if you decide to go the route to also

includeBuild

subproject-api

from

subproject

, you even have to add it. But please don't just do that, as it is just not the same if you one time use it as subproject and one time as subbuild.

Thanks for looking at this. This dependency model is indeed a design flaw that we should get rid of. But for the time being, we've to deal with it. There are several elements in your answer and I’m a bit confused on the best way to fix this… Would you mind pushing your best proposal on a branch when you have time?

This dependency model is indeed a design flaw that we should get rid of.

What do you mean? As described, the major flaw is that you use

subproject-api

as subproject in one project and as separate subbuild in the other. There is nothing that should be able to force you to deal with it instead of fixing it. As described, use it consistently, either as subproject or as subbuild.

I’m a bit confused on the best way to fix this…

There is no "best" way, there are just alternatives and what is the best depends on your situation and what you want. But I guess my first suggesting could make sense, that's why I made it first and just provided you with an alternative. What is unclear with

Instead include the

subproject

build from

main-project

and remove the settings script from

subproject-api

.

?

Would you mind pushing your best proposal on a branch when you have time?

Not at a computer right now and "best" is a matter of opinion. But I think you should be able to change one method call argument and delete one file. :-)