Gradle 6.5.1: 'Could not find any convention object of type JavaPluginConvention'

[onpaws]

Environment:
macOS, openjdk@11, SpringBoot 2.2.2.RELEASE

• Jib version:
  2.4.0
• Build tool:

$ gradle --version

------------------------------------------------------------
Gradle 6.5.1
------------------------------------------------------------

Build time:   2020-06-30 06:32:47 UTC
Revision:     66bc713f7169626a7f0134bf452abde51550ea0a

Kotlin:       1.3.72
Groovy:       2.5.11
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          11.0.8 (Oracle Corporation 11.0.8+11)
OS:           Mac OS X 10.15.6 x86_64

• OS:

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.15.6
BuildVersion:	19G73

Description of the issue:
Thanks for making Jib, it's a nice improvement over the naive Dockerizing a JAR approach I was heretofore using.

I recently inherited a Gradle project and trying to deploy it using Jib.
The trouble is, adding the Jib plugin and running it seems to fail, and I'm not sure what's wrong.
As I understand it, installing Jib (and most Gradle plugins) should usually be a matter of adding jib to the plugins section of the root build.gradle, like so:

plugins {
    id "net.ltgt.apt" version "0.20"
    id "io.spring.dependency-management" version "1.0.8.RELEASE"
    id "com.google.cloud.tools.jib" version "2.4.0"
}

However when I do that, gradle jib fails, in fact gradle by itself fails too. I added another plugin as an experiment (id "org.ajoberstar.pipeline-test" version "0.2.0-rc.13") and gradle still worked OK, so something about Jib seems to be a factor.

$ gradle

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'MyApplication'.
> Could not find any convention object of type JavaPluginConvention.

Meanwhile I was able to get Jib 2.4.0 working in a separate SpringBoot/Maven project, also Java 11, same machine, etc. So I suspect something related to Gradle+Jib interaction. Feels like it's probably not a Jib bug but something related to Gradle or perhaps this project. Not enough of a Java or Gradle expert to know what to do next...any tips would be appreciated. Thanks!

Expected behavior:
gradle jib --image=example should work in the usual way.

Steps to reproduce:
These repro steps are a 'best guess' b/c I am awaiting permission to share the source. I can, however, share the build.gradle and that's included below.

1. Create a Gradle springboot project running 2.2.2.RELEASE
2. Add id "com.google.cloud.tools.jib" version "2.4.0" to build.gradle:plugins
3. Run gradle

build.gradle contents:

plugins {
    id "net.ltgt.apt" version "0.20"
    id "io.spring.dependency-management" version "1.0.8.RELEASE"
    id "com.google.cloud.tools.jib" version "2.4.0"
}

ext {
    springBootVersion = "2.2.2.RELEASE"
    testcontainers = "1.12.0"
}

subprojects {
    apply plugin: "java"
    apply plugin: "net.ltgt.apt-idea"
    apply plugin: "io.spring.dependency-management"

    dependencyManagement {
        imports { mavenBom("org.springframework.boot:spring-boot-dependencies:${springBootVersion}") }
    }

    group = "com.example.application"
    version = "2.1.0"
    sourceCompatibility = "11"
    targetCompatibility = "11"

    repositories {
        mavenCentral()
    }

    configurations {
        developmentOnly
    	runtimeClasspath {
    		extendsFrom developmentOnly
    	}
        compileOnly {
            extendsFrom annotationProcessor
        }
    }

    dependencies {
        compileOnly "org.projectlombok:lombok"
        testCompileOnly "org.projectlombok:lombok"
        annotationProcessor "org.projectlombok:lombok"
        testAnnotationProcessor "org.projectlombok:lombok"
    }
}

Log output:
If it's helpful please just ask, happy to provide.

Additional Information:
Convention object, JavaPluginConvention 🤔 not sure what that means...
https://docs.gradle.org/current/javadoc/org/gradle/api/plugins/JavaPluginConvention.html

[loosebazooka]

It looks like you're applying the jib plugin on the root project (which as far as I can tell, you don't want).

You root build.gradle could do something like

plugins {
   ...
    id "com.google.cloud.tools.jib" version "2.4.0" apply "false"
   ...
}

subprojects {
   ...
   apply plugin "com.google.cloud.tools.jib"
   ...
}

The error is just saying that the project you are applying jib on doesn't have the java plugin applied (since that's only applied on subprojects).

[loosebazooka]

@onpaws I see that you've put a 👍 on the answer. I will close this issue for now. Please reopen if this issues persists or create a new issue if you encounter something new.

[onpaws]

@loosebazooka thank you.

The apply false detail is new to me, I tried it and it has improved things, kind of :)

$ gradle

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/paws/projects/MyApplication/build.gradle' line: 16

* What went wrong:
A problem occurred evaluating root project 'MyApplication'.
> Could not get unknown property 'plugin' for project ':api' of type org.gradle.api.Project.

Since I last wrote I learned this project is a so-called multi-project build, with two includes in settings.gradle

pluginManagement {
    repositories {
        gradlePluginPortal()
    }
}
rootProject.name = 'MyApplication'
include 'application'
include 'api'

application & api both have their own settings.gradlebuild.gradle and I'm now trying to figure out if I need to add jib in each of those.
It seems like there would need to be one entrypoint for Docker, so not too sure how to say which project 'wins'...

[onpaws]

TIL evidently GitHub won't let me re-open my issue apparently b/c I'm not a member of this repo - I guess maybe I should open a new one? If you have a preference, please let me know @loosebazooka , thanks :)

[loosebazooka]

so in my example I missed a :

- apply plugin "com.google.cloud.tools.jib"
+ apply plugin: "com.google.cloud.tools.jib"

which is causing your error.

There is only one settings.gradle per gradle execution (and per multimodule project). It's not clear to me why this project your inherited has multiple settings.gradle. Unfortunately this is not the right forum to explore generic gradle build issues.

[onpaws]

so in my example I missed a :

- apply plugin "com.google.cloud.tools.jib"
+ apply plugin: "com.google.cloud.tools.jib"

which is causing your error.
Awesome, have corrected that.

There is only one settings.gradle per gradle execution (and per multimodule project). It's not clear to me why this project your inherited has multiple settings.gradle. Unfortunately this is not the right forum to explore generic gradle build issues.

Whoops my mistake, I meant to say build.gradle files.
I think fixing the colon as you indicated might sort me out nicely though - I'll post back! Thanks again :)

[onpaws]

Yep, moving forward on this for sure. Now, gradle runs again, and gradle jib is getting somewhere. Thanks! 🥳

Now, I'm moving onto the next one
Main class was not found, perhaps you should add a mainClass configuration to jib
I would think SpringBoot has a conventional "entry point" and I'll have to teach Jib about it.
So far I tried this:

jib {
        to.image = 'example'
        container.mainClass = 'Application'
    }

Which jib happily compiles, so I think that's good? However actually running the docker image fails...

Error: Could not find or load main class Application
Caused by: java.lang.ClassNotFoundException: Application

Intending to research how Spring works. Thanks again @loosebazooka !

[chanseokoh]

container.mainClass = 'Application'

Are you using the default Java package (unnamed package)? Otherwise, you should use a fully-qualified class name. For example, com.example.Application.

[chanseokoh]

And make sure to apply the Jib plugin only in the application subproject that has a main class. We've seen people incorrectly setting up a multi-module project where they apply Jib to subprojects that create dependencies for the main application subproject.

[onpaws]

Thanks @chanseokoh! That was indeed what I tried next.
In the end, things tentatively seem to be working when I follow the steps @loosebazooka outlined in this issue.
#1722

So I think this issue is safe to close.
One day, I'm not sure if it's possible, but I hope to learn how to properly extract node_modules dependencies the way you guys have cleverly handled here in the Java world. Here's to the time we save with fast image builds 🥳