Gradle Plugin for Java Generation from CRD

[teimyBr]

Is your enhancement related to a problem? Please describe

At the Moment we are using this

tasks.register('createCrds') {
    doLast {
        def config = new io.fabric8.java.generator.Config()
        def runner = new io.fabric8.java.generator.FileJavaGenerator(config, new File("${projectDir}/chart/templates/Test.yaml"))
        runner.run(
            new File("${buildDir}/generated/sources/crds/main/java")
        )
    }
}

Describe the solution you'd like

Like fabric8-maven-plugin
We want also a Plugin for Gradle to generate CRD and not using this above.

Describe alternatives you've considered

No response

Additional context

This Code above leeds issue when fabric8 is updating this methodes we are using

[andreaTP]

Hi @teimyBr and thanks for filing this issue!

I changed this issue title since, at the best of my understanding, you are generating Java classes out of a given CRD; feel free to correct me.

All in all, I do believe that publishing a Gradle plugin that simply exposes the functionality (like the CLI and the Maven plugin) would not require a major effort.

But @manusa is the expert here for sure, so waiting on his feedback 🙂

[teimyBr]

@andreaTP yes exactly i want to generate the java classes.

The way we using this at the moment is not the best, because we using classes and methodes which changes time by time.

A Gradle Plugin would be the best way.

[manusa]

All in all, I do believe that publishing a Gradle plugin that simply exposes the functionality (like the CLI and the Maven plugin) would not require a major effort.

If we create the plugin like we do on JKube (https://github.com/eclipse/jkube/tree/master/gradle-plugin), then it's a matter of creating the module (with specific coordinates) and publishing it to Maven Central along with the rest.

If we do it the official way (https://docs.gradle.org/current/userguide/custom_plugins.html) it will be harder and also make our release process even more painful.

---

In any case, with what we have currently, it would be kind of trivial for any gradle project to create a custom task that would generate the classes just by accessing the java-generator API. The good thing about Gradle is that it's just a script.

new FileJavaGenerator(Config.builder()/*....*/.build()).run($target)

[teimyBr]

def config = new io.fabric8.java.generator.Config()
        def runner = new io.fabric8.java.generator.FileJavaGenerator(config, new File("${projectDir}/chart/templates/Test.yaml"))
        runner.run(
            new File("${buildDir}/generated/sources/crds/main/java")
     )

yeah we are using this workaround.

So i unterstand it i makes it harder.

Maybe is it possible when you make changes on FileJavaGenerator or io.fabric8.java.generator.Config(), that this mandatory in the release Notes ?

[andreaTP]

Despite the fact that we don't plan for major structural changes to the core classes of the java-generator at this point, I do believe that a grade plugin would be a nice-to-have feature.

I think that I will eventually try to contribute it 🙂

[alfsch]

All in all, I do believe that publishing a Gradle plugin that simply exposes the functionality (like the CLI and the Maven plugin) would not require a major effort.

If we create the plugin like we do on JKube (https://github.com/eclipse/jkube/tree/master/gradle-plugin), then it's a matter of creating the module (with specific coordinates) and publishing it to Maven Central along with the rest.

If we do it the official way (https://docs.gradle.org/current/userguide/custom_plugins.html) it will be harder and also make our release process even more painful.

In any case, with what we have currently, it would be kind of trivial for any gradle project to create a custom task that would generate the classes just by accessing the java-generator API. The good thing about Gradle is that it's just a script.

new FileJavaGenerator(Config.builder()/*....*/.build()).run($target)

Yes, I'll do it in exact this way. Unfortunatly nearly with every release of fabric8 we had to fiddle around with the parameters, since it's internal API somehow.

[andreaTP]

So far we have been quite "liberal" about the public API of the java-generator, please note that we are(still) calling it a "preview" release.

Thanks a lot for your input, we will consider promoting the generator out of preview (maybe with version 6.5?).

[manusa]

In case we think this is stable enough to GA/remove preview note, it would make sense delaying the implementation of the Gradle plugin until after that. This will allow us to create a more stable extension.

[andreaTP]

Quick update that I'm struggling to find the time to get to this 😞
If anyone wants to give it a stab I'll be happy to support and review progress on this though! 🙂

[andreaTP]

Quick heads up that we are going to break the configuration API of the java-generator, hopefully, for the last time: #4875

[fabiobrz]

If we create the plugin like we do on JKube (https://github.com/eclipse/jkube/tree/master/gradle-plugin), then it's a matter of creating the module (with specific coordinates) and publishing it to Maven Central along with the rest.

If we do it the official way (https://docs.gradle.org/current/userguide/custom_plugins.html) it will be harder and also make our release process even more painful.

Hi @manusa, just double checking here - IIUC the difference you're outlining here is between implementing it as a Maven project (the jkube example) vs. a regular Gradle one (the official way), right?

CC @andreaTP

[andreaTP]

that's correct @fabiobrz 👍

[fabiobrz]

that's correct @fabiobrz 👍

Cool, thanks @andreaTP!