I'm trying to port this to kotlin and merge it wit...

# gradle

[barteks2x]

I'm trying to port this to kotlin and merge it with my buildscript for last 3-4 hours and I'm completely stuck... https://github.com/PaleoCrafter/Dependency-Extraction-Example/blob/coremod-separation/build.gradle

[barteks2x]

I tried exactly that syntax, and the ForgeGradle plugin game me that error. I also tried:

tasks {
    "coreJar"(Jar::class) {
          // logic here
    }
}

with the same result

[jlleitschuh]

What error?

[barteks2x]

* What went wrong:
A problem occurred configuring root project '1.12'.
> coreJar  is not a jar task. Can only reobf jars!

[barteks2x]

this is part of ForgeGradle trying to tell me something

[jlleitschuh]

Can you link to your current code?

[barteks2x]

it comes from the equivalent of this:

reobf {
    coreJar { mappingType = 'SEARGE' }
}

which is

configure<NamedDomainObjectContainer<ReobfTaskFactory.ReobfTaskWrapper>> {
    create("coreJar").apply {
        mappingType = ReobfMappingType.SEARGE
    }
}

my current code: https://hastebin.com/sicemaruna.scala (this is with addition to my project)

[jlleitschuh]

You're sure that:

configure<NamedDomainObjectContainer<ReobfTaskFactory.ReobfTaskWrapper>>

is equivalent??

[barteks2x]

yes, I'm sure

[jlleitschuh]

So in full, you have something like this?

task coreJar(type: Jar) {
    //...
}

configure<NamedDomainObjectContainer<ReobfTaskFactory.ReobfTaskWrapper>> {
    create("coreJar").apply {
        mappingType = ReobfMappingType.SEARGE
    }
}

[barteks2x]

well, I have

tasks {
    "coreJar"(Jar::class) {
          // logic here
    }
}

which I saw in samples

[barteks2x]

but basically, yes

[jlleitschuh]

Try putting:

configure<NamedDomainObjectContainer<ReobfTaskFactory.ReobfTaskWrapper>> {
    create("coreJar").apply {
        mappingType = ReobfMappingType.SEARGE
    }
}

Into an afterEvaluate block and see what happens

[barteks2x]

well, I actually have 2 of create("something").apply { blocks, I just realized that it could be bug in that plugin that makes it break when 2+ are there

[barteks2x]

it seems to work with afterEvaluate

[barteks2x]

but Ihave no idea why it's needed when it works without kotlin dsl

[jlleitschuh]

I agree that it's strange.
I'm going to guess that there's an execution ordering problem.

[barteks2x]

Considering the strange things the FG plugin does, it's not that unlikely

[barteks2x]

well, now I actually get this

* What went wrong:
Execution failed for task ':reobfCoreJar'.
> org.gradle.jvm.tasks.Jar_Decorated cannot be cast to org.gradle.api.tasks.bundling.Jar

[barteks2x]

and the previous error is straneg too because that part that does throw new GradleConfigurationException(jarName + " is not a jar task. Can only reobf jars!"); is in afterEvaluate in that plugin's code

[jlleitschuh]

So, Gradle weirdness, there are actually two Jar tasks. One is just an interface for the other one.

[barteks2x]

is it just a change in gradle internals in some version that broke the plugin?

[barteks2x]

OH

[barteks2x]

default imports broke it

[jlleitschuh]

Yea, that.

[jlleitschuh]

Because the default Jar is probably different than the one the plugin expects.

[barteks2x]

Should I report it as an issue that the org.gradle.api.tasks.bundling.Jar needs fully qualified name to be used?

[barteks2x]

it's impossible to use without using fully qualified name

[jlleitschuh]

Yea, I think the forge gradle plugin needs to be updated.

[barteks2x]

to use the other jar task?

[jlleitschuh]

Yea,

[barteks2x]

Good luck with getting ANY change into ForgeGradle...

[barteks2x]

also to me it looks like org.gradle.api.tasks.bundling.Jar is actually in the API. Shouldn't that one be actually imported by default?

[jlleitschuh]

@bamboo or @eskatos Can you explain the weird Jar api, why there are two of them, ect... to me again because I still don't really understand.

I know it has something to do with not breaking the API.

[barteks2x]

and yet it turned out to be a breaking change

[jlleitschuh]

True, it probably changed during a major version bump. ¯\_(ツ)_/¯

[barteks2x]

wekk, breaking change when used together with kotlin's default imports

[jlleitschuh]

I mean, these are the same default imports used by Groovy too.

[barteks2x]

I would be able to debug it if I could add breakpoints in gradle code...

[jlleitschuh]

Supposedly you can, but I haven't ever been able to get it to work.

[barteks2x]

You can add them but they don't work

[barteks2x]

It's also unlikely it can be fixed in FG because it probably still builds against gradle 2.x

[jlleitschuh]

Well that's their problem.
That's really old, they should update their build.

[barteks2x]

its not their problem if they don't claim compatibility with gradle 4.x

[jlleitschuh]

¯\_(ツ)_/¯

[barteks2x]

anyway, now I can try to make publishing to maven work

[eskatos]

Like Jonathan said, Kotlin DSL default imports are the very same as the ones you get in the Groovy DSL. But thanks to the Groovy magic it may work anyway, but Kotlin doing strict type checking forces you to use a fqcn here.
Agreed that FG should update their build, or you have to live with the fqcn.

[eskatos]

After taking a closer look, that’s on Gradle & Kotlin DSL. The Groovy DSL actually imports the “old” Jar task by default. This will be fixed in the upcoming Gradle 4.3.