automate killbill-api implementation generation about killbill-plugin-framework-java HOT 3 CLOSED

@sbrossie I imagine that the workflow that we're using so far as follow:

1. Edit classes in killbill-api.

2. Build killbill-api so it's available in our local maven repository, and

   2.1. Then set this killbill-api latest version (local SNAPSHOT version) to either killbill-base-plugin / killbill-plugin-framework-java that we're currently working on. Or

   2.2. Push changes in killbill-api and merge it so github action build this killbill-api artifact and published to sonatype, and we can set killbill-base-plugin / killbill-plugin-framework-java that we're currently working on to latest sonatype artifact.

3. In killbill-base-plugin / killbill-plugin-framework-java, check for errors/classes that need to re-implements anything based on update from point 1.

From my understanding, the killbill's api-pojo aims to replace tedious task in point 3. No?

Or, do you want that during killbill-api build, it should automatically:

1. Checkout killbill-base-plugin / killbill-plugin-framework-java
2. Re-generate the boilerplate code.
3. Build and test
4. If pass, then push it back to killbill-base-plugin / killbill-plugin-framework-java github origin repository

Either way, I think we need to

1. Publish api-pojo maven repository (central and sonatype)
2. Depends on your answer for question above, we could
   • Utilize exec-maven-plugin to execute code generation
   • Develop a maven plugin to execute code generation

Thought?

from killbill-plugin-framework-java.

@xsalefter The task is about automating the re-generation of the killbill-api POJOs inside killbill-plugin-framework-java -e.g https://github.com/killbill/killbill-plugin-framework-java/tree/master/src/main/java/org/killbill/billing/account/api/boilerplate.

That is, whenever we make killbill-api changes, the killbill-api version would be updated from the base pom.xml - we are not trying to automate that part- but then we want an easy way to regenerate the killbill-api POJO using the api-pojo tool. Right now, it's very manual.

As far implementation goes, exec-maven-plugin is one option, as it would plug into the build. Another simpler option would be to have a script we can run (not part of the build) - in this case, we could also have a CI job which allows to start the script from GH. Feel free to experiment with whatever is easier / simpler.

from killbill-plugin-framework-java.

@sbrossie continuing discussion at this PR:

I think we should still at point invest into a GH workflow so we can simply press a button and get that generated.

Am I right that the idea is like we have "run workflow" in GitHub action for releasing an artifact? If so:

1. Where do you think that action/button should be exist? I think it is in killbill-plugin-framework-java. WDYT?

2. After the button clicked, which action do you prefer:
   2.1. Generate classes, merge it automatically with target branch, and then do the snapshot/release.
   2.2, Create new branch, generate classes, and send PR automatically for review (just like github dependabot)

from killbill-plugin-framework-java.