Migrate off of bash script for packaging steps

[plaird]

As a spring-boot rule maintainer
I would like to have a more powerful language backing the packaging stage of this rule
Such that the rule is easier to maintain

Consider Python3 or Go something else.

https://github.com/salesforce/bazel-springboot-rule/blob/master/tools/springboot/springboot_pkg.sh

[plaird]

Please don't pick this up without posting here first.

I have soured on using Go for this rule. We did that internally in our monorepo with another tool, and discovered the downsides. With only one small tool using Go, it was irritating to see the need to download the toolchain on CI and dev machines. We have since moved other Go projects into our monorepo, so it is not an issue anymore. But we have to consider that many springboot rule users will not have a Go toolchain otherwise in their repo, and so imposing that on them would be unpleasant.

Python is fine, as long as we verify the PY2/PY3 compatibility. We have had some headaches with that internally though.

So overall, I am less displeased with dinosaur bash now, than when I filed this issue. I am not sure I want to change.

[joeljeske]

I am most concerned with windows support as opposed to language maintainability. Any thoughts on windows?

[plaird]

@joeljeske Ah, thanks for keeping me honest. You are right. I haven't been in a workplace with Windows for many years, I didn't consider that.

I have filed #25 to track the Windows support specifically, with this issue (migrating off of bash) as a necessary dependency to achieve that.

[plaird]

I just overhauled the dupe class checker feature, which is now entirely written in Python3. Before it was half Bash, half Python. We now support the use of a captive Python (not the system Python) to make the Python usage hermetic. See our captive python docs. So one thought is to just keep going, and reimplement everything with Python3 and eliminate Bash.

But Python3 doesn't come for free. You have to make sure Python3 is installed (captive, or system level) on every build machine.

I wonder if rewriting the rule in Java is the way to go here. Bazel always has a Java JDK. And if you are picky about JDK, they are finally getting Java toolchain support wired up in Bazel. If we go this direction, we could forklift Singlejar as the base implementation and extend from there.

[plaird]

My company has an upcoming internal hackathon. I just assigned this issue to myself. I am going to try and tackle a migration from bash -> Java.

[plaird]

Unfortunately, a day into the hackathon an urgent issue arose and I got pulled off of this fun work. I have some starting framework code. done locally, but nothing functional. I essentially implemented the command line processor for the invocations of the packager. I also identified Zip4J as an essential dependency. But that was it.

I will try to carve out some time over the next few weeks to get at least something useful into a branch, so we can iterate from there.

[plaird]

Time changes things. I am now thinking with the Starlarkification effort going on in Bazel, a mostly Starlark implementation would probably be achievable. I have been devoting all of my open source time to IDE work but hope to get back to rules_spring in a few months.