Gradle importing scrips like in ant or in java


(Raja Nagendra Kumar) #1

Unable to split gradle script in two files and use import…

i.e build.gradle script has content like

import fnd.cmn.bu.BUConsts import fnd.cmn.bu.uts.tng.TNGConsts

defaultTasks BUConsts.CLEAN, TNGConsts.TEST, TNGConsts.OPEN_TEST_REPORT;

While BUConsts.gradle is in fnd\cmn\bu directory

package fnd.cmn.bu;

public interface BUConsts {

public static final String BLD = ‘bld’;

public static final String CLEAN = ‘clean’;

public static final ArrayList SRC_DIRS = [“fnd/cmn/src”, “lapos/cmn/src”] … }

When I do gradle at command prompt (my classpath does has current directory in its path)

is reporting that imports are not found…

This should have been very obvious like in java… however in gradle even after two days we are unable to crack…

Pl. advise… what is wrong… I am not interested in putting these scripts in buildSrc\src\main\groovy

Regards, Nagendra


(René Groeschke) #2

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:

ext{
 BUConsts = [:]
 BUConsts['BLD'] = 'bld'
 BUConsts['CLEAN'] = 'clean'
 BUConsts['SRC_DIRS'] = ["fnd/cmn/src", "lapos/cmn/src"]
}

now you can reference the clean task in your build.gradle file as

apply from:'buconst.gradle'
  defaultTasks BUConsts.CLEAN

hope that helps,

cheers! René


(Raja Nagendra Kumar) #3

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

Regards, Nagendra C.T.O www.tejasoft.com


(Peter Niederwieser) #4

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.


(nagendra.raja) #5

Thank You Peter.

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

buildscript

{

dependencies

{

classpath files([“C:\temp\out\production\lapos”]);

}

}

This is working if I explicitly compile before gradle build firing and put the class at C:\temp\out\production\lapos

It’s just not how Groovy works

I shall keep the intent of Groovy design in mind.


(Peter Niederwieser) #6

Is it possible to compile depedendent groovy file during buildscript lifetime.so that I can give explicit classpath like this

That’s exactly what ‘buildSrc’ is for. Alternatively, you can compile the code on your own (e.g. with a separate build).


(nagendra.raja) #7

buildSrc

Can I customize buildSrc directory to my own.

So that, by the time buildscript block executes all my gradle or groovy files are compiled and converted to classes.

To which directory all the class generated go to…


(Peter Niederwieser) #8

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.