The README mentions the wrong version of ci.common on the buildscript classpath when using plugins DSL. Don't need this though since we've been publishing our plugin.

[scottkurz]

I noticed following along from the doc: https://github.com/OpenLiberty/ci.gradle/blob/main/README.md#adding-the-plugin-to-the-build-script that the instructions:

Alternatively, you can apply the plugin through the plugins block. You'll need to add the plugin's runtime dependencies to the buildscript classpath when using this method.

buildscript {
    repositories {
        mavenCentral()
        mavenLocal()
    }
    dependencies {
        classpath ('io.openliberty.tools:liberty-ant-tasks:1.9.9')
        classpath ('io.openliberty.tools:ci.common:1.8.20')
    }
}

plugins {
    id "io.openliberty.tools.gradle.Liberty" version "3.5.2"
}

had the wrong version of ci.common listed. The LGP v3.5.2 builds against ci.common v1.8.23.

Since there was an InstallFeatureUtil ctor signature change in ci.common across these versions, I realized the older v1.8.20 in my config wasn't actually being picked up using v3.5.2.

I then noticed the OL starter generates a config like this, without the buildscript:

plugins {
    id 'war'
    id 'io.openliberty.tools.gradle.Liberty' version '3.5.2'
}

So why is this in the doc? Maybe for older versions of Gradle??

Digging through the history here's how this doc was added:

• Adding plugins block test and updating publishing plugins #517
• Class not found when applying plugin through plugins block #441
• https://groups.io/g/openliberty/topic/71446503#453

I don't see a version mentioned in the groups.io message.

I tried to recreate the error at a few versions, 5.1 (which is what we were building ci.gradle with at the time), 5.6.4, 6.9.4, and a couple from 7.4.x and 7.6.x...and never recreated it.

Can we just delete this doc then instead of worrying about keeping the ci.common version up-to-date?

@mattbsox ?

[scottkurz]

OK, I see that the change in LGP v3.1 was to publish our plugin, as Matt suggested with this comment:

An additional solution would be to publish a fat plugin jar containing the ant and common dependencies to the Gradle plugins repo.

So mystery solved, now the question is how to update the doc.

[mattbsox]

I think it makes sense to update the documentation to reflect all of that. I don't know that there were any specific updates to fix that issue aside from moving to a different publishing plugin.

[mattbsox]

Wondering if the repo that we pull the plugin from will affect that behavior. Gradle might resolve it differently when using a Maven repo, like we have in the documentation, or the Gradle plugin repo that the plugins block uses by default.