Hello, To use a different gradle scripts, you have to apply it to your build.gradle file via
apply from:'buconsts.gradle'
Using interfaces for defining constants is not best practice in gradle. Instead, you can use a very simple approach to define constants in buconst.gradle using a map:
Thank you very much for the reply. Could you pl. let me know more
Using interfaces for defining constants is not best practice in gradle
Any reason for this… Ant I am so frustrated using strings every where… as most mistakes happen due to string typing. Instead using Interfaces would mean compiler time checking and having the single definition of string every where. I am looking for developing properties which are in Object form (OOProperties), i.e Properties Key and Value paris can come from evaluation of Objects/classes… no hard-coded strings.
I shall try the MAP approach as per your example. I would still prefer Interface, I can say find usage of BLD const etc…and many more advt… with interface extend, inheritance and overriding etc…
apply from:‘buconsts.gradle’
I have used apply this way now I see buconsts.gradle is compiling. However it fails by saying
Could not find property ‘BUConsts’ on root project ‘prodNag’
Why is it thinking .BUConsts as property…can it look at it as a class/interface. I also tried by using both apply and import, then it still says import not found
As a side note, I see anything as per apply and from convention can not have package declaration packaging & imports in java is a great dependency management… happy to know more about how gradle handles this differently
Instead using Interfaces would mean compiler time checking
Gradle scripts are written in Groovy, which is a dynamically typed language. Using constants in interfaces won’t get you any compile time checking. At best, it will get you some IDE support, but currently you’d have to manually set this up in the IDE.
However it fails by saying Could not find property ‘BUConsts’ on root project ‘prodNag’
‘apply from:’ doesn’t (and isn’t intended to) make classes declared in the applied script visible to the caller. In short, you can’t add classes to Groovy scripts at runtime. It’s just not how Groovy works.
I see anything as per apply and from convention can not have package declaration
The desire to use package statements is a sign that you are doing too much in the build scripts. You should externalize such code into ‘buildSrc’ or an external Jar. This will give you other advantages like full IDE support, proper testability (e.g. with JUnit), distribution via Ivy/Maven repositories, etc.
apply from: doesn’t (and isn’t intended to) make classes declared in the applied script visible to the caller. In >short, you can’t add classes to Groovy scripts at runtime
Is it possible to compile depedendent groovy file during buildscript lifetime.so that I can give explicit classpath like this
No, you cannot change the location of the ‘buildSrc’ directory (if you mean that). The reason is that the ‘buildSrc’ project has to be built before the main build’s build scripts can even be evaluated. This is due to Groovy being a compiled language.