@frozenlock the Uberjar does end up there.

@mikerod I forgot to mention: with profiles. :target-path in a profile is respected for compilation, but not for the uberjar.

@frozenlock which profile is it? How are you running the uberjar task to include this profile?

:target-path "target/%s"
  
  :profiles {:uberjar {:aot         :all
                       :omit-source true
                       :auto-clean  false}
             :dev     {:plugins [[lein-shell "0.5.0"]]}
             
             ;; profiles to generate test uberjars
             :updater-test  {:uberjar-name "updater.jar"
                             :target-path  "target/test/lifecycle/updater"
                             :main         updater.updater}
             :main-app-test {:uberjar-name "main-app.jar"
                             :target-path  "target/test/lifecycle/main_app"
                             :main         updater.updater}}

  :aliases
  {"test-lifecycle" ["do" "clean," "with-profile" "updater-test:main-app-test" "uberjar"]}

Then lein test-lifecycle

Uberjars are put into target/uberjar instead of target/test/....

@frozenlock maybe because the profiles aren’t marked with :leaky

https://github.com/technomancy/leiningen/blob/master/doc/PROFILES.md#profile-metadata

But I don’t really expect necessarily you’d have to. But it’s possible.

Thanks, I'll try that first thing in the morning!

Follow-up : adding ^:leaky fixes the issue. Thanks!

@frozenlock ok, good. it’s a bit frustrating to me still

I was thinking/hoping that with-profile would be unconditionally respected

this was your actual project.clj setup right? you weren’t using “composite” or “partially composite” profiles too?

like did you have a :profiles that composite-style merged in :updater-test and/or :main-app-test?

eg.

:profiles 
{:test [:updater-test {<stuff>}] ...}

Yes, it was the actual setup.

ok, so it just still strips out profiles, even when you gave them with-profiles

what version of lein too? just to be cleear @frozenlock

Leiningen 2.9.1 on Java 11.0.4 OpenJDK 64-Bit Server VM

Just to be clear: everything in the profile appears to be kept (including uberjar-name), but the generated uberjar is in the wrong directory.

Oh, more interesting then

but ok, so :leaky maybe just giving it higher priority in some profile merge step later

that’s a deeper hole to trace through then hah

@frozenlock sorry to drill with questions, but did the “normal” jar file end up in the correct :target-path, but not the uberjar? or did both jars ignore your :target-path?

Normal jars behave as expected. It's really just the uberjar that was ending at the wrong (uberjar profile) :target-path.

ok

I don’t know the whole reason still, but I suspect it’s because the :uberjar profile is perhaps auto-marked as :leaky

and perhaps it already somehow inherits the :target-path from the root, and that ends up taking priority in the profile merging

Mostly this is speculation though

I don’t see :leaky playing a role in the merge fn’s though, so I don’t think that’s correct - boo