Add Dekorate support

[pgressa]

Dekorate in latests stable version 1.0.1 covers in this MR:

• Kubernetes
• OpenShift
• Knative
• Prometheus
• Jaeger
• Service Catalog
• Halkyon CRD

Left to do:

• review documentation hints
• move dekorate version to bom https://github.com/micronaut-projects/micronaut-core/blob/2.1.x/build.gradle#L92
• dekorate now supports only Kotlin and Java, Groovy is not supported
• dekorate does not support Kotlin + Gradle Gradle + Kotlin doesn't work dekorateio/dekorate#632

[pgressa]

Not sure whether to link to kubernetes micronaut documentation. Strictly speaking, to generate k8s manifests, that module is not needed.

[pgressa]

• this module is not now required, so either I'll add dependency on micronaut-kubernetes, or will remove this method. WDYT?

[ilopmar]

Some minor changes and a question. Overall looks good!

[pgressa]

@graemerocher @ilopmar what's left to discuss:

• to make Dekorate work properly, either openshift, kubernetes or knative modules must be included. These features distinguished by DekoratePlatformFeature Anyway to make it work properly, I have added this DekorateFeatureValidator. So basically this dependency causes that the test does not add an unmodifiable map to config FAILED Question is how to make that test work. What comes to my mind is, in case no DekoratePlatformFeature is among selected features, to add default Kubernetes one.

[alvarosanchez]

@pgressa nice! I see they removed their support for Micronaut in dekorateio/dekorate@466e892#diff-4f6f5cc3fccf73f75ae9ccf4ad2f4d1e

I think we should have a better integration so that stuff like hardcoding the port in @Port isn't necessary.

[pgressa]

@alvarosanchez from that commit it seems they never supported it at all, as the classes are basically empty.

What you mean better support integration? Do you mean to implement framework support to dekorate?

This PR basically introduces and configures the dekorate annotations that should produce manifest with similarconfiguration to the one that the Kubernetes feature produces. Once micronaut-projects/micronaut-core#4012 will be merged the readiness/liveness probes should be used here as well.

[alvarosanchez]

Yes, implement framework support for Dekorate. Not in starter, but as part of micronaut-projects/micronaut-kubernetes#46 (which is what I originally intended when I created the issue).

Regarding the commit, the classes weren't empty. You need to click "Load diff" to see them. However, they didn't do a great job at detecting the port: dekorateio/dekorate@466e892#diff-e5672fa55806c7dfd54773de95f3fedbL40

If you look at the Spring Boot support, they actually read the configuration files to detect the port, among many other things.

[pgressa]

:D well I'm aware of the "Load diff" button.. but exactly because they won't read configuration I would say the integration was more a generated project, otherwise they wouldn't remove it. But that's not important at this moment.

What is important like how to proceed with this PR. Could you elaborate more on the integration from micronaut-kubernetes and how it would be supporter from starter project. Because from my poor understanding of how are things working:

• from dekorate PoV contains framework support what means that once knative/openshift/kubernetes is on class path, then respective platform manifests are generated. Of course except the services like jaeger, prometheus, ... .
• or from micronaut side, we have this starter project or respective modules

But how would that module work? Like we would have our annotation processor that feeds the values directly into dekorate generator?

[alvarosanchez]

:D well I'm aware of the "Load diff" button

Sorry, I didn't understand you correctly in the first place.

But how would that module work? Like we would have our annotation processor that feeds the values directly into dekorate generator?

Exactly that, the same as the Spring Boot integration does.

I'm ok with moving this PR forward if then we work on such integration.

[graemerocher]

What @alvarosanchez says makes sense, you want to be able to set the correct port automatically I guess.

[pgressa]

@graemerocher @alvarosanchez guys, I can go for it if you think current version is not usable for users. I would personally prefer to merge this one, then introduce the module that will feed the values from within the app context, and after that I would adjust the starter project and remove hard-coded values and leave just the annotation. WDYT?

[alvarosanchez]

I already said I'm ok with doing that.

[pgressa]

@alvarosanchez OK, I'm just not sure whether @graemerocher requires those changes or not :)

[pgressa]

Ok so seems like 1.0.2 works with gradle and java. Unfortunately Kotlin is not working with our setup, so I have created new issue there dekorateio/dekorate#632 and will disallow combination of Kotlin + Gradle in DekorateValidator so we can move forward. So here's the bump to 1.0.2 micronaut-projects/micronaut-core#4131

[pgressa]

@graemerocher pls review

[jameskleeh]

@pgressa The dekorate kotlin + gradle is supposedly fixed. dekorateio/dekorate#632. Can you test/review and update this PR?

[pgressa]

@jameskleeh oh I didn't notice they fixed... going for it

[pgressa]

@jameskleeh works.. will force push fix