chore: move fetching credentials to util class and minor cleanups

[pratik151192]

Re-used some redundant code. Also wanted to get a feel of the PR/Git ecosystem on the team :)

[pratik151192]

I realize my second commit message should have been of the form "Fixing spacing and spotlessJava check issues"; however, we should squash and merge this so it shouldn't matter anyway. One question:

• I am not sure how we run the Git workflows locally? I did run the Gradle tools through my IntelliJ which spit out errors associated with spotless checks but didn't find a way to literally run this file on my local https://github.com/momentohq/client-sdk-java/actions/runs/5406490424/workflow?pr=291

[cprice404]

I realize my second commit message should have been of the form "Fixing spacing and spotlessJava check issues"; however, we should squash and merge this so it shouldn't matter anyway. One question:

* I am not sure how we run the Git workflows locally? I did run the Gradle tools through my IntelliJ which spit out errors associated with spotless checks but didn't find a way to literally run this file on my local https://github.com/momentohq/client-sdk-java/actions/runs/5406490424/workflow?pr=291

Yeah there's not really a way to run the workflows locally, at least not an easy one that I've found.

One approach we can use if the workflow gets too complex is to just put all of the logic into some shell scripts in a scripts directory, and then have the workflow call those, and the developer can also run them before commit if they like.

Thanks for the PR! I will defer to Nate on reviewing the changes since he's done most of the work in this repo.

[cprice404]

nice catch :)

[cprice404]

Thanks for the PR!

If this was production code this would be an awesome change. However, for the stuff in these example files, we are expecting that users may want to copy/paste code from one of these files directly into their app. So we are trying to avoid them having to navigate through multiple files in the project in their IDE. Or like, if they didn't clone the repo and they are just looking at the code on github, then they'd have to figure out where the util code lived and open two browser tabs to copy all the code they need.

So I think for examples we probably have a preference for "self-sufficient" over DRY. Let me know if you have different thoughts!

[pratik151192]

No that makes total sense. I did see this class called ExampleUtils class which had the utility methods of printing the start and end banners so thought it'd be okay. I will like it to be consistent and get rid of that util as well in that case and make every example class it's own standalone with no helpers. We can also rework on this PR https://github.com/momentohq/client-sdk-java/pull/294/files and have a separate example altogether that uses secrets manager.

Let me know if that makes sense and I can abandon these two PRs and create a fresh one that's more like BasicExampleWithSecretsManager in the examples directory; and also remove any util classes even if it's for the banner.

[cprice404]

yep! you nailed it. What happened with that ExampleUtils class is that in Nate's original PR where he created it, he had done exactly what you did with the auth, and I made this same comment. So he unrolled the auth stuff but left the banners, which I didn't care as much about. Personally I have no objection to you rolling those back too.

And yes, we should set up a separate example project to house the secrets manager thing :) that way the gradle build for these basic examples doesn't have a dependency on secrets manager, in case people are copying our gradle project for the examples. We'll need to break up the examples dir into some subdirs for different kinds of examples, which is a thing we did very recently for the node.js SDK and probably needs to happen to all of the SDKs over time. :)