The example seems to suggest you still need the Clojure CLI installed for this to work?

yep. Still nowhere near a state i could walk up to a stock Java dev and convince them, but enough to show the concept imo

the next steps would be 1. Think way more about how to expose the basis concept 2. Fill out and document the build tools wrapper 3. Wrap the clojure CLI’s functionality - probably making a graalvm executable with a “simplified” api probably along the lines of

jproject --help
jproject --tree
jproject --pom
jproject run src/Something.java
jproject run --alias=build build/Build.java
jproject run --alias=build build/Build.java --argForBuildProgram 123

Terrifying

good

I feel bad that you're spending time making it

why so?

just pouring concrete over all that lovely clojure

makes for good rebar

I've added options to those build tasks at least a dozen times in the last 6 months. every time I do that, you'll have to add new fields and methods and whatever

if anyone uses it, which i doubt

and if i get it into a workable/marketable state, which is doubtful. Especially considering that no IDE resolves deps.edn dependencies without a clojure plugin so any effort to make it seem “java native” is probably moot

and anyone who is comfortable installing a clojure plugin might as well just write the build program in clojure

NOW you can feel bad

You sure are dedicated to this 🙂

Not really, and if I did I would use jbang, https://jbang.dev/

but can jbang let me stay up until 4am writing a script for test coverage

public final class GenerateCoverage {
    public static void main(String[] args) throws IOException {
        var execFileLoader = new ExecFileLoader();
        execFileLoader.load(new File("jacoco.exec"));
        var htmlFormatter = new HTMLFormatter();
        var fileMultiReportOutput = new FileMultiReportOutput(new File("target/coverage/html"));
        var visitor = htmlFormatter.createVisitor(fileMultiReportOutput);

        var coverageBuilder = new CoverageBuilder();

        for (var file : Files.walk(Path.of("target", "src"))
                .filter(Files::isRegularFile)
                .map(Path::toFile)
                .toList()
        ) {
            var analyzer = new Analyzer(execFileLoader.getExecutionDataStore(), coverageBuilder);
            analyzer.analyzeAll(file);
        }

        var bundle = coverageBuilder.getBundle("project");
        visitor.visitInfo(
                execFileLoader.getSessionInfoStore().getInfos(),
                execFileLoader.getExecutionDataStore().getContents()
        );
        visitor.visitBundle(bundle, new ISourceFileLocator() {
            @Override
            public Reader getSourceFile(String packageName, String fileName) throws IOException {
                var resource = GenerateCoverage.class.getResourceAsStream(
                        packageName.replace(".", "/") + "/" + fileName
                );
                if (resource == null) {
                    return null;
                }
                return new InputStreamReader(resource);
            }

            @Override
            public int getTabWidth() {
                return 4;
            }
        });
        visitor.visitEnd();
    }
}

Amazing! I'll certainly change my java code on clojure-lsl to use that!

This reminds me of a Java API I once wrote for SCI. After 2 months I just gave up and told people to make their own dedicated Clojure wrapper and call that from Java.

What a terrifying adventure!