Name of the jar? `java build jar/foo` -> foo.jar, `java build src/dog` -> dog.jar. Dependencies? It's okay to use a dependency list file for these - I guess I

Name of the jar? `java build jar/foo` -> foo.jar, `java build src/dog` -> dog.jar. Dependencies? It's okay to use a dependency list file for these - I guess I don't consider this config compared to the stuff I usually find in a Gradle or Maven file. The thing I'm alergic to is all the stuff that isn't a dependency list. In Go, these go in a go.module file that's automatically updated by the build tooling, which runs instantly & has a cache you never need to think about. Go has the advantage of import paths being URLs that specify the dependency too, but I think my Go-For-Java tool would use reverse package import search from an online service to map eg com.foo.bar.something.Potato to the appropriate package "foo-bar" from Maven Central or whatever. Building that index seems like a trivial program to write for the average Java engineer. The more I think about this "go for java" idea, the more I want to build it "in anger" just to see how off-base I am. Maybe I really am just going to re-implement or wrap sbt, mill, gradle, https://www.jbang.dev/ https://www.jbang.dev/ idk. It just feels like the experience could be an order of magnitude simpler as an end-user with some conventions strictly enforced by the tooling.