I am not sure what happens. It's a case where if I run an uberjar task (with aot) from a module it just works but from a process that iterates over modules and run it for each deployable it then fails compiling the mains (just the mains). /tmp/compile-clj1025453397036198757/compile-clj/foo/main.class and the command starts with : java -cp /tmp/compile-clj1025453397036198757/compile-clj:... anyway I ll dig further

it's difficult to give a full picture in current state.

@U050SC7SV Maybe you are skipping some binding/context when iterating over the project dirs? Here's what we do at work:

(doseq [p projects]
      (println "\nRunning: uber on" p)
      (let [project-dir (str "projects/" p)
            aliases     (with-dir (io/file project-dir) (get-project-aliases))]
        (binding [b/*project-root* project-dir]
          (bb/clean {})
          (bb/uber (assoc (:uberjar aliases)
                          :compile-opts {:direct-linking true}))
          (bb/clean {}))))

no I do that religiously already

and everything is using absolute paths in the cp currently

do you aot in build-clj uberjar task?

no you don't with this snippet

without aot this works fine but aot is required in this context

the comment in compile-clj makes me think I either forget something or process/java-command is not running from the right dir

;; java-command will run in context of project-dir - basis, classpaths, etc ;; should all be relative to that (or absolute like working-compile-dir)

Yes, we AOT. See the linked build-clj code.

Are you explicitly building a basis? How/where? Note how we have to bind t.d.a's context separately to deal with reading/merging EDN files and extracting aliases. And we do all of the tools.build stuff inside the binding of *project-root*

yes, there's no merging going on, it's quite straightforward. we just run the command from a different project context than the one being compiled/uberjared

I ll step back and re-check the code that creates the basis, I was sure it was fine (it works for all the rest), but maybe I missed something

https://github.com/seancorfield/build-clj/blob/main/src/org/corfield/build.clj#L234 is the code for the uber wrapper that does pom.xml creation, copying files, compilation, and uber all in one task.

thx

that part is more or less identical as ours apparently

The (:uberjar aliases) piece pulls in options like

:uberjar
  {:uber-file "../../../build/uberjars/api-1.0.0.jar"
   :main api.main}

(and :main causes :ns-compile to be populated, as [api.main] for the example above)

Feel free to share some of your build code via DM with me if you don't want to share it in the channel -- maybe I can spot what's wrong?

the error starts with one of the (compile 'foo.main) call in the generated script failing with a NPE (I guess it can't find the file)

Or perhaps the output path for the generated classes is missing/`nil`?

but I can definitely see it under /tmp/compile-clj1025453397036198757/compile-clj/foo/main.class

no it's here (if you mean the binding in the generated script)

it fails at compile-clj step

hmm I said something wrong, should be the clj file, not the class file

Hard for us to tell without seeing your scripts 🙂

if the compile-clj fails, it does not delete the temp dir where it's working

I know! it's very useful 🙂

so you can go look at the entrails if that's helpful

I have been doing that for a while

you should be able to fully reproduce the step at that point

I can repro, but not fix it

somehow the http://clj.co/compile call fails to find the clj file that has the main

the src dir of the project/module in question is in the classpath

Figured it out :) It is a bit convoluted I will spare you the details, but it's not caused by t.build or t.deps.

It's a problem with that main.

learned a bit about the internals for all this along the way, I guess we can file this one as "not a total waste of time"