Override extension variable when included gradle file using "apply from"

Help/Discuss
1

i have some common gradle file with some tasks defined and with some ext variables defined. For ex:

common.gradle

ext {
    myVar1 = 'abc' //some default value
}

tasks.register('myTask') {
  println "$myVar1"
}

i’m including this gradle file to access the tasks in my project. Here i want to override that variable and when myTask gets called, it should have overriden value.

myproject/build.gradle

apply from '../common.gradle'

ext {
  myVar1= "xyz" //actual value
}

when i call gradle myTask its printing “abc” instead of “xyz”. I tried putting doLast closure in myTask but still its printing “abc” only.

I need to include common.gradle in multiple projects, where i need to set project specific values

How to achieve this?

2

Some points:

  • Do not use script plugins (the things you apply using apply from), they are not recommended anymore and often just are the cause of major confusion and problems, while at the same time being restricted in functionality. You for example cannot use a plugins { ... } block, it has strange class loading issues, …
    Instead better use precompiled script plugins, either in buildSrc or - what I prefer - in an included build. They look almost like normal build scripts, can be applied like any other plugin and have the full functionality available.
  • Do not use ext variables. Imho everytime you use them, you should feel dirty, as they in almost all cases are just a quick and dirty work-around instead of doing it properly, like for example registering an own extension that consumers can configure that is typesafe and can also be made properly lazy using the Property/ Provider apis properly.
  • With tasks.register('myTask') { println "$myVar1" } you are reading myVar1 at configuration time of the task. So if with that variant the value is abc it most probably means you (or some plugin you use) are somewhere breaking task configuration avoidance. Because you correctly use tasks.register to avoid configuration, but as abc is seen, the task is confiugred befor you set the value to xyz. So I guess you somewhere have a tasks.all { ... } or a tasks.withType(TheTypOfThatTask) { ... } or similar that breaks task configuration avoidance and causes the value to be read before you set it to a different value. (Something you could also easily mitigate by using tha lazy apis instead of the hacky extra properties). So you should probably investigate your build where you waste configuration time by configuring too many tasks. :slight_smile:
  • If it really still does not work using doLast wich delays the reading of the extra property to the runtime of that task, my guess is, that you either did not do it, or maybe set the value again to abc later, for example by applying the script plugin again or something similar. If you don’t find it, you would need to provide an MCVE, because while being bad practice, it works perfectly fine here with doLast from what you described.
3

Thanks a lot for valuable inputs. Unfortunately, cannot change existing structure due to legacy constraints and want to do it as simple as possible. But i will keep in mind your feedback and will implement in coming projects.

For now, i removed that prop in common.gradle (as anyway, common.gradle cannot be run independent).