So for those following the saga of me trying to present tools.deps in a way that is oriented toward java projects for an audience of 0 - how would people feel about this syntax

jproject javac --class-path ,,, -d target/classes 
jproject javac --module-path ,,, -d target/classes 
jproject -A:build javac --module-path ,,, -d target/classes 

javac --class-path $(clj -Spath) -d target/classes
javac --module-path $(clj -Spath) -d target/classes 
javac --module-path $(clj -A:build -Spath) -d target/classes

Basically the hint i took from bach was that there is a somewhat sensible workflow with standard java tools to compile a modular project, so i’m leaning into supporting the ToolProvider SPI from the command line

Available in every alias
-------------------------
jar          create an archive for classes and resources, and manipulate or restore individual classes or resources from an archive
javac        read Java declarations and compile them into class files
javadoc      generate HTML pages of API documentation from Java source files
javap        disassemble one or more class files
jdeps        launch the Java class dependency analyzer
jlink        assemble and optimize a set of modules and their dependencies into a custom runtime image
jmod         create JMOD files and list the content of existing JMOD files
jpackage     tool for packaging self-contained Java applications

Available in :google-java-format
-------------------------
google-java-format

Available in :jreleaser
-------------------------
jreleaser    release automation tool for Java projects.

Available in :junit
-------------------------
junit        launches the JUnit Platform from the console

so those invocations would look kinda like

var basis = Basis.builder().alias("junit").build();
var javac = ToolProvider.findFirst("javac").orElseThrow();
var javacRunResult = javac.run(
    System.out, 
    System.err,
    List.of(
        "--class-path",
        basis.path(),
        "-g",
        "-d",
        "target/classes"
    )
);
if (javacRunResult != 0) {
    System.exit(javacRunResult);
}
// more code here

and the reason i would want that vs the api that tool.build provides is that a java project might want to use --module-path instead of class-path

and if have a CLI that directly exposes tools, you could write a jar file that if its in the alias you get run, compile, build, etc - all the modern conveniences you can get from assuming a project layout or structure (like “only modules” or “everything follows the src/main/java, etc structure”)

but not every tool would be uniform in how it takes the computed dependency path, hence the idea of just having people write ,,,

at which point the only thing I would really be taking from tools.build is the uberjar shortcut - the basis comes from tools deps and the rest of it - file system utils, git utils - isn’t that crucial

so i could make a few artifacts • one that depends on tools.deps and provides a Basis class • one that depends on the Basis class and provides a sub-interface of ToolProvider that would let tools optionally give more info to jproject

public interface ProjectToolProvider extends ToolProvider {
    // Can be used in lieu of hard coded dep information
    String description();
    // alleviate the need for that ,,, hack if the tool can make do without it
    Optional<ToolProvider> inBasis(Basis basis);
}