Publish to Maven Central

[tobinam]

Dear Clarisma,

Would you consider publishing gol-tool to Maven Central? This would help me simplify my build. I would then convert to .gol files from within the application.

Thanks for your consideration.

[clarisma]

Hi @tobinam, thanks for submitting this! (Sorry I've been a bit slow lately responding to issues).

Yes, I've considered publishing the GOL Tool as a library. This shouldn't be too complicated, since the current POM is already building a JAR, which is then packaged into a "fat JAR" with its dependencies. It looks like I would just need to add a secondary target, which uploads the stand-alone JAR to Maven Central (essentially the same process as for the GeoDesk jar).

There's a bit of a wrinkle: I've been working on a prototype for the next version of the GOL Tool, which requires some significant changes to support incremental updates. This is based on the new GeoDesk C++ toolkit (which is coming out next month). Even without optimizations, gol build now runs twice as fast, consuming only a third of the memory, so I'm fully committed to continue on this path.

Unfortunately, this slightly complicates the modularization effort on the Java side. I'm contemplating a wrapper class that invokes the main functionality of the new GOL Tool via JNI. This would still require bundling 4 separate native binaries as part of the JAR (one for each platform we currently support: Windows, Linux, MacOS-Intel and MacOS-ARM). Another option I'm researching is how the various GUI wrappers for Git distribute and invoke the Git executable, and imitate that approach.

The good news is that the binaries of the new GOL Tool will only be a few megabytes each, and will be self-contained (no other DLLs or other files needed, all dependencies are linked statically), so their combined size will be less than the distribution size of the current GOL Tool.

As for the current version, it appears that you would like to invoke GolTool::main directly (e.g. for the build command), without having to bundle the fat-JAR (and essentially duplicating dependencies). Is this correct? As far as your build system, are you using a CI/CD pipeline, or simply a Maven POM?

In terms of user feedback, would you need a handler that receives progress updates from a long-running command like gol build, or is it sufficient to read stderr? (In the latter case, your application would need to replace System.err with a custom stream prior to invoking the GOL Tool).

Ideally, I'm looking to craft an API that exposes the functionality of the current GOL Tool, which would also allow drop-in replacement once the new native-binary version ships.