Update Demo/Sample Project with the new plugins

[Iñaki Villar]

Update Demo/Sample Project with the new plugins

[Mozart Petter]

@cdsap I've been playing with this while testing a few changes to address #231.
One thing I've notice is that after changing the sample to use com.cdsap.talaiot.plugin.base I'd get an error when trying to access jsonPublisher:

* What went wrong:
Script compilation error:

  Line 20:         jsonPublisher = true
                           ^ Unresolved reference: jsonPublisher

1 error

With configuration:

talaiot {
    publishers {
        jsonPublisher = true
    }
}

After some digging, I realized that BaseExtension.publishers() takes a PublishersConfiguration type, which is not aware of jsonPublisher property, since it belongs to BaseConfiguration:

    fun publishers(block: PublishersConfiguration.() -> Unit) {
        ....
    }

Changing it to take a BaseConfiguration block solves the issue. Does it make sense? I can provide a prototype if the issue is not clear.

[Iñaki Villar]

Hi, I think the problem is coming when we try to include in the classpath of the build script the dsl configuration.
The plugins have included e2e tests to test the whole integration with Gradle:
https://github.com/cdsap/Talaiot/blob/master/library/plugins/base/base-plugin/src/test/java/com/cdsap/talaiot/plugin/base/BasePluginTest.kt#L22

I tested different scenarios, first using groovy and defining everything in the root build.gradle of a given project:

buildscript {
    ext.kotlin_version = "1.4.10"
    repositories {
        jcenter()
        maven {
            url  "http://oss.jfrog.org/artifactory/oss-snapshot-local"
        }
    }
    dependencies {
        classpath  "com.cdsap.talaiot.plugin:base:1.3.6-SNAPSHOT"
    }
}

apply plugin: "com.cdsap.talaiot.plugin.base"
talaiot {
    publishers {
        jsonPublisher = true
    }
}

this case is correct, then testing with kts we can reproduce the problem, but is not something new, if we test a previous snapshot version, we have the same problem in kts:

buildscript {
    repositories {
        jcenter()
        maven ( url = uri("http://oss.jfrog.org/artifactory/oss-snapshot-local") )

    }
    dependencies {
        classpath("com.cdsap:talaiot:1.3.4-SNAPSHOT")
    }
}

apply(plugin = "com.cdsap.talaiot")

talaiot {
    publishers {
        timelinePublisher = true
        jsonPublisher = false
    }
}

That's the behavior(now) of the kts implementation. If you are wondering why is working with the release builds it's because the release plugins are published to the Gradle plugin portal. This allows us to use:

plugins {
    id("com.cdsap.talaiot") version "1.3.5"
}

talaiot {
    publishers {
        timelinePublisher = true
        jsonPublisher = false
    }
}

The plugin configuration uses the Gradle Plugin repository and we don't have the problem including in the buildScript section for kts.
We cannot push snapshots for the Plugin Portal and we are using OJO snapshots. That's we have that difference.
Sample has an additional for the module:
https://github.com/cdsap/Talaiot/blob/master/sample/settings.gradle.kts#L6

Finally, if you are finding these problems in other projects one way to apply the plugin(in case you are injecting scripts or you want to customize the logic) you can use:

apply from: stuff.gradle.kts
buildscript {
    repositories {
        maven {
        }
    }
    dependencies {
        classpath(PLUGIN)
    }
}

apply<Plugin>()
configure<PluginExtension>() {
}

So we need to find the better way to implement the sample:

• First, we want to cover all plugins, or just one/some plugins?
• Update the settings.gradle from the sample to cover the different modules

[Mozart Petter]

Thanks for the explanation. I thought it could be a type issue, not very familiar with Kotlin DSL to be honest. I will play a bit more with the sample to try and learn more about it. I've updated the settings to "work" with all plugins in a not very elegant way, hehe.

First, we want to cover all plugins, or just one/some plugins?

The way I envision it, we would have many sample modules, each with a different configuration. No need to cover all, since some may be very similar.

I'd like to have at least one Groovy sample as well if possible. That should help with #117.

[Mozart Petter]

@cdsap I can look into this during this week. May I assign it to myself? Is there any particular samples you want to have?

[Iñaki Villar]

Sure, no problem.
At the end, because all the plugins are in the plugin portal we can rely in them and we can include some basic samples for 2-3 plugins.
What do you think?

[Mozart Petter]

What do you think?

Sounds good. I'll wait for #258 to be merged and published. Then I should be able to prepare the samples. 👍

[Iñaki Villar]

new PR creating 2.0 release, ignoring 1.4