Buildscript {} in subprojects {} ignored?


(Gabriele Del Prete) #1

I cannot make plugin repositories to work in a multi-project environment.

Specifically, if I put the buildscript {} element with repositories and dependencies within the subprojects{} in the root build script, it looks like it’s ignored (compiling subprojects fail).

I need to put the buildscript {} element into each subproject’s build script.

This happens both when using “flatDir” and local-dir Ivy repositories.


(Francis Galiegue) #2

Hello,

I encounter the same problem. I was trying to use the fatjar plugin (https://github.com/musketyr/gradle-fatjar-plugin) and, at first, I copy/pasted the instructions in a separate common.gradle file which I ‘apply(from: “common.gradle”);’ in build.gradle.

It failed to work until I moved the instructions into build.gradle itself…


(Francis Galiegue) #3

Note: groovy 2.1.5, gradle 1.6


(Luke Daley) #4

I’d recommend just putting it in the root project (i.e. not in a subprojects {} block). All the children will inherit this classpath automatically.


(Francis Galiegue) #5

In my case it was not in a subproject block. I had a ‘buildscript’ block in another .gradle file which I included in build.gradle using ‘apply(from: “other.gradle.file”);’.

And the block was completely ignored :confused:


(Luke Daley) #6

In that case, that buildscript block refers to the classpath for that script, not the whole project.


(Francis Galiegue) #7

Ah, so ‘apply(from: “somewhere.else”)’ is not a “real” include then? Is there such a thing?

I guess my lack of gradle-fu shows :confused:


(Luke Daley) #8

Ah, so apply(from: “somewhere.else”) is not a “real” include then? Is there such a thing?

There’s nothing like this, no.


(Francis Galiegue) #9

And are there any plans to add it?

It’d be really nice, to be honest; for instance, it would allow not to have to create a ‘settings.gradle’ file just to override the root project name!


(Luke Daley) #10

And are there any plans to add it?

Not at this time. It’s not trivial.

It’d be really nice, to be honest; for instance, it would allow not to have to create a settings.gradle file just to override the root project name!

How so?


(Francis Galiegue) #11

How so?

I’d like to be able to do a very simple thing: define all of the project’s group, name, version, (Java) language version/compatibility in one file.

And right now I can’t do it. If I try and define ‘name’ in a property file and/or alternate .gradle file, I get rejected. If I try and define ‘{source,target}Compatibility}’ in a property file or in ‘settings.gradle’, they are happily ignored.

I can certainly believe this is a nontrivial task to achieve, but when it is achieved, it will make gradle usage all the more easy.

I mean, I have been doing gradle for two days only, and I am able to do more than what I was ever able to do with maven. But as far as sourcing, and using, custom properties/tasks/etc is concerned, ant stays the reference here.