Hi everyone. Are there (supposedly) any functional differences between running gradle on the project's

build.gradle

file and using another build file with

-b

? I have made a copy of the actual

build.gradle

and added some stuff, put that into a different file and ran it with

-b

. It doesn't seem to work, whereas when the same file is named

build.gradle

and ran normally without

-b

, it works

Is there a reason you use an ancient version? Btw. the whole

-b

in the meantime got deprecated or even removed.

@Vampire I am a contributor to a modernization & migration project called Konveyor. I'm working on Gradle support, and some old projects may use older versions of Gradle, therefore we need to support them.

I see. Maybe if you elaborate on the use-case why you intend to use an alternate build script I or someone else can recommend a better tactic.

I have basically created a task that downloads dependency sources, which is what I need to do. It needs to be as backwards compatible as possible. Then, I need to use this task in whatever gradle project we need to analyze

Use an init script to add your task instead. You then give that with

-I ...

.

But the

task

function is not available in init scripts

But the

task

function is not available in init scripts

Correct, not top-level. The context of an init script is not a project. Have a look at the documentation for init scripts. And even if it were available, using it is a bad idea anyway. It does not leverage task-configuration avoidance. Well, if you only use it if you know for sure that task is going to be executed, it might be ok, but it is better practice to always use task-configuration avoidance compatible API.

I might need a

doLast

?

Of course. Anything you do outside

doLast

or

doFirst

is not done at task execution time, but at configuration time. So even in the build script it is a bad idea. The work is a task should be done in execution phase. Otherwise you could also right away not use a task if you anyway not do any work at execution time.

Great... Apparently

Cannot call TaskInputs.files(Object...) after task has started execution

.

Of course, changing the task configuration at execution time, especially the task inputs it output is very problematic and makes little sense. You need to do configuration work at configuration time and execution work at execution time.

I'm going to have to embed the task in the project's

build.gradle

file, which sucks

No, you just have to do it right. :-) And as I said, doing it as you do it right now I'm the build script might "work better" as you naturally do the actions later, but it is still highly problematic and fragile. Better do it properly. :-)

Hey @Vampire, thank you for your feedback