Inconsistent `require`ing of `asdf-jar`

[fosskers]

The experiments continue. I am attempting this:

import org.armedbear.lisp.Interpreter;

public class Main
{
    public static void main(String[] args) {
        Interpreter i = Interpreter.createInstance();
        i.eval("(require :asdf)");
        i.eval("(require :abcl-contrib)");
        i.eval("(asdf:make :asdf-jar)");  // Dies here. Same result with `require`.
        i.eval("(asdf-jar:add-to-asdf \"/home/colin/code/common-lisp/abcl-test/abcl-test-all-0.0.1.jar\")");
        i.eval("(asdf:load-system :abcl-test)");
        i.eval("(abcl-test:launch)");
    }
}

This is in attempts to get a standalone, runnable .jar with both my underlying Lisp code and ABCL bundled into one thing that is launchable by this Main class.

Both in a standalone abcl repl and here I have trouble with consistently being able to actually (require :asdf-jar). Most of the time it fails with:

Don't know how to REQUIRE ASDF-JAR.

This is despite abcl-contrib existing on the classpath (and (require :abcl-contrib) succeeds). Once in a standalone REPL I noticed it recompile a bunch of things and then after that it would work. However, it never succeeds through the Java interop shown above.

If instead I do asdf:make on it as shown above, as recommended in its own README, I'm told:

Component :ASDF-JAR not found

Do you know what's going on here? Do I need to go deeper and write something more customized myself?

Another approach could be to produce a script instead of a fatjar that just wraps a call to abcl on the original Lisp jar, but that would require the user to have an abcl installation to begin with. Downstream users of mine are looking for the ability to distribute fatjars.

[easye]

I haven't tried your usecase specifically, but if you are looking for a "all-in-one" packaging for ABCL, I think that @alanruttenberg has provided the support you are looking for in the ABCL-AIO target in the Ant build system. By populating system.lisp with customized load strategy, the resulting jar should ship your desired implementation. You'll need a local writable filesystem for the fasls from the compilation, but it should work.

I'll try to find some time to help with the standalone use-case for ABCL, as well as get an abcl-1.9.3 release out which meets any upstream needs.

[fosskers]

Thank you, I'll look into abcl-aio as well. To update you on my current progress, I have been doing some prototyping in vend to handle the provisioning of Java dependencies from Maven central as well. Yes, abcl-asdf fills a similar niche, but if vend does it itself it can have more control, and it better fits the spirit of vendoring (I pull the deps to vendored/java/, alongside Lisp deps).

I'm able to parse .pom files for dependency information and recursively determine the proper classpath additions, allowing me to load them into an ABCL repl as it starts. That in itself is useful enough, but I'm trying to determine if I can go as far as producing usable fatjars as well. If not, I'll leave vend to strictly handle the dep provisioning and nothing more.

[fosskers]

@alanruttenberg , if you have a moment, could you comment on the strategy that @easye mentioned above?

[alanruttenberg]

This is the commit I did for abcl-aio

It only made it so that the contrib source was included in the jar, and looked for there. It did not include compiled files. My aim wasn't so much to avoid having them compiled as to not to have to worry about two jars instead of one.

I may have understood how the fasls were included for the main part of abcl, at some time, but I don't remember now. compile-system.lisp is where you want to look. Whatever it does, it manages to include all the fasls for the main part of ABCL.