Sourcesets not correctly set (>0.2.5)

[rnorth]

On a fairly new codebase where I'm using this plugin, I've encountered what seems like a regression in versions greater than 0.2.5.

It would appear that after this version the sourcesets and compileJava dependency on generateJooqClasses are no longer automatically set up correctly: what I've observed is:

• generateJooqClasses not being run at all in a normal build (e.g. clean check). This can be worked around by adding compileJava.dependsOn(generateJooqClasses) to the build script.

Following that workaround, it's still not good news:

• Compilation failures in main code that depends on any generated classes
• IDE no longer detects the build/generated-jooq directory as a source directory

I've not had time to dig into why this is happening, but for me both of the following workarounds work:

• Stick with v0.2.5 of the plugin
  or
• Add the following to build.gradle:

compileJava.dependsOn(generateJooqClasses)

sourceSets {
    jooq {
        java {
            srcDirs "${buildDir}/generated-jooq"
            compileClasspath += main.compileClasspath
            runtimeClasspath += main.runtimeClasspath
        }
    }
    main {
        java {
            compileClasspath += jooq.output
            runtimeClasspath += jooq.output
        }
    }
    test {
        java {
            compileClasspath += jooq.output
            runtimeClasspath += jooq.output
        }
    }
}

I can put together a repro example if you'd like, but before I do so, does anything spring to mind?

[adrianskrobaczrevolut]

Hey @rnorth 🙂
That's actually very interesting, because >0.2.5 are the versions where I actually fixed the ugly way we used to configure source sets 😅 b12e666#diff-83a8e2a543bc56687e2b75ec62457ef6R93
One thing that crosses my mind is that on previous versions the plugin was automatically applying the java plugin now it's not doing that anymore(click) and let users apply either that or Kotlin plugin depending on needs. Could you try explicitly applying java plugin to the project ? If that doesn't help it would be really helpful if you could post some simple setup that reproduces the problem.

[rnorth]

Ah, maybe I've hit an edge case against the new way of doing things then!

I'll create an example repository: unfortunately I already have the java plugin applied, so it must be some other nuance.

Thanks for getting back to me quickly!

[rnorth]

Quick repository to demonstrate this:

https://github.com/rnorth/jooq-plugin-issue9-repro

• Master branch uses v0.3.3 of the plugin along with manually-added sourcesets. Compiles OK.
• This branch uses v0.3.3 without the manual sourcesets. Compilation of code in main fails.
• This branch downgrades the plugin to v0.2.5 and removes the manual sourcesets. Compiles OK.

I hope this helps - if you spot anything I'm doing wrong please do let me know.

[adrianskrobaczrevolut]

Thanks for the repo it was helpful 👍 I did some digging and I found what is the problem. Current implementation of the plugin assumes that the Java plugin will be applied before the jooq plugin and seems like it's not the case for this project. What bothers me is that we actually have the test case for Java project compilation here, that passes but when I copy exact same setup as a standalone project it fails the same way your reporo exmple 🤔 I'll do some more digging later maybe I'll be able to reproduce the problem with the test somehow, but anyways I'll fix the problem in the next release. Unfortunately until that you will have to stick to the workaround you proposed or to older version or in the more complex setups with subprojects it seems to work just fine. Thanks for raising the issue and I'll keep you posted here once I fix it 👍

[adrianskrobaczrevolut]

@rnorth @victorlopezsalazar should be now fixed in latest 0.3.4 version. Let me know if it works for you guys 🙂

[rnorth]

Great, thanks so much! I’ll give it a try and let you know.

[victorlopezsalazar]

In my case going from 0.3.2 to 0.3.4, I got the following stacktrace:

org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':generateJooqClasses'.
   ...

Caused by: java.lang.NoSuchMethodError: org.flywaydb.core.api.configuration.FluentConfiguration.defaultSchema(Ljava/lang/String;)Lorg/flywaydb/core/api/configuration/FluentConfiguration;
        at com.revolut.jooq.GenerateJooqClassesTask.migrateDb(GenerateJooqClassesTask.kt:165)
        at com.revolut.jooq.GenerateJooqClassesTask.access$migrateDb(GenerateJooqClassesTask.kt:23)
        at com.revolut.jooq.GenerateJooqClassesTask$generateClasses$$inlined$use$lambda$1.execute(GenerateJooqClassesTask.kt:153)
        at com.revolut.jooq.GenerateJooqClassesTask$generateClasses$$inlined$use$lambda$1.execute(GenerateJooqClassesTask.kt:23)
        at com.revolut.jooq.Docker.runInContainer(Docker.kt:38)
        at com.revolut.jooq.GenerateJooqClassesTask.generateClasses(GenerateJooqClassesTask.kt:152)

the config for the task is the following:

generateJooqClasses {
    schemas = ["my_schema"]
    basePackageName = "package"
    customizeGenerator {
        generate = new Generate()
                    .withRelations(true)
                    .withDeprecated(false)
                    .withRecords(true)
                    .withImmutablePojos(true)
                    .withFluentSetters(true)
                    .withJavaTimeTypes(false)
                    .withPojosEqualsAndHashCode(true)
    }
}

worth to mention that I also have the configuration to replace the flyway version enabled:

resolutionStrategy {
            dependencySubstitution {
                substitute(module("org.flywaydb:flyway-core"))
                        .with(module("org.flywaydb:flyway-core:5.2.4"))
            }
        }

I will play around with configs later when I got a little time to do it.

[adrianskrobaczrevolut]

@victorlopezsalazar that's actually to be expected 😅 That's because versions >0.3.2 use configuration options introduced in flyway 6.x.x. I don't plan on downgrading flyway version used by plugin, but maybe we can sort this out somehow by using map properties instead of FluentConfiguration#defaultSchema, so it's more backwards friendly, but let's track that in this issue: #10

[rnorth]

I’ve upgraded to 0.3.4 and removed the workarounds, and it seems to work perfectly! Thanks for solving the problem @adrianskrobaczrevolut!