Verify Code Format as well as License Header presence during CI build

[vorburger]

I'm raising this issue prompted by https://github.com/google/adk-java/pull/102/files#r2132521541:

Is your feature request related to a problem? Please describe.

IMHO it would make the life of committers (maintainers) easier if this project would verify Code Format as well as missing License Header presence during CI build (and thus cause red build failures).

IMHO it would also make the life of contributors (PR raising community members) easier if this project had a very easy way to auto-format code according to the standards that this projects expects its code to be formatted with.

Describe the solution you'd like

The following is for discussion, but if it was up to me, I would go about this simply by adding a suitable pre-commit hook configuration, for both the Google Java Code Formatters, and the license headers checker/adder. (I have used and done this in a project of mine, and ready to copy/paste this here.)

Describe alternatives you've considered
Waste time of both committers and contributors by leaving "nit pick" comments about such things on PRs.

Using pre-commit would avoid requiring Python to be installed to run the pre-commit, but IMHO nowadays that shouldn't really be an issue. (And one could still locally build the project without it; just without the pre-commit.)

An alternative to avoid ^^^ would be to integrate the Google Java Code Formatters using (one of) its Maven Plugins. But I don't know (haven't looked into) a Maven license header checker, and as far as I know that's harder to easily cleanly integrate nicely as an automagic pre-commit.

Additional context

I'm happy to help by proposing a PR for this, if the project's committers concur that this would be useful?

@glaforge @Poggecci @cornellgit do you have any thought about / input on this?

[glaforge]

We could set up checkstyle since committers will be building with Maven?

[vorburger]

Checkstyle is obviously great, and I've happily used it for 25 years! But I suspect that contributions to the code in this repository will very likely be expected to be formatted with Google's Java Format (GJF). And https://github.com/google/google-java-format actually really is pretty awesome! (I've even made some, very very minor, contributions to it myself!) And keeping a Checkstyle config manually aligned with the format that Google's Java Format expects is going to be a huge unmaintainable maintenance nightmare, IMHO. So personally I would recommand that we simply adopt (hear, enforce) GJF here in this project. Thoughts?

PS: Just to avoid confusion, the "Java/Building with Maven" vs. https://pre-commit.com (Python) dimension is tehcnically completely orthogonal to GFM or not (because we could integrate GFM validation and autoformat through various mechanisms).

[glaforge]

I didn't know GJF! Sounds like it's going to be the best fit for the job here.
Ideally, we should be able to run it from Maven (and potentially from IDEs), and make sure that when GitHub actions build the project, they go through GJF too.

[shukladivyansh]

+1 to both google-java-format and licence header pre-commit checks.

agree with @vorburger on google-java-format since that's the one we use internally and send cls with.

[vorburger]

/assign @vorburger #blockedBy #155 -- I'll (only) look further into this after we conclude that.

[vorburger]

#183 (WIP?) takes stab at the license header part of this.

[vorburger]

FTR: I've worked a bit on this today, and raised the x3 PRs shown above.

I'm wondering if spotify/fmt-maven-plugin#184 and spotify/fmt-maven-plugin#197 (with spotify/fmt-maven-plugin#196) will be a problem for us.