So after a lot more experimentation with classifiers, dynamic version strings, etc., it looks like the only way I'm going to be able to achieve what I'm after (single project.clj that can emit two different, JVM-specific artifacts that have different upstream dependencies, depending on which JVM the build is run on) is by twizzling the project name component in the defproject form. e.g.

(def project-name (... logic that calculates a project name based on the JDK we're running on ...))

(defproject project-name "0.1.0-SNAPSHOT" ...)

Maybe you can write a macro that takes the project-name as arg, and returns the defproject form you want?

although that may run into problems with the fact that you want to calculate the project name at run time, not compile time.

Possibly-effective hack: shell/clj/Python/etc. script that writes the project.clj file and does build/deploy/whatever commands, then tweaks the project.clj file and repeats.

@deactivateduser10790 I thought you were going with a version string change? at this point, the best I can think of is similar to what @andy.fingerhut mentioned concerning having an external script that picks the different jvm’s for you to run lein with, so a defproject setup similar to this

So it is flexible to adapt to different jvm versions

@andy.fingerhut yeah that thought crossed my mind too, but it felt to me like a bridge too far - like I'm definitely headed down a bad path. 😉

@mikerod it turns out that when you use a version number suffix, the Maven machinery still only has a single POM file, and I need two (recall that my upstream dependencies differ, depending on which JVM is in use).

The a script could run it like

# jvm x 
LEIN_JAVA_CMD=jvm-x-path lein <task>

# jvm y
LEIN_JAVA_CMD=jvm-y-path lein <task>

yeah, at this point though, I’d go with the version appraoch

Sure, but I can't make assumptions about which JVM(s) consumers of the library are using.

and just manage the artifacts via an external script

This is a general purpose library that (hopefully!) many other folks will consume and enjoy. 😉

you have conditional deps depending on jvm?

So I can't just assume they have the same JVMs installed that I do, let alone in the same locations.

so you have to need to know

Yep.

the script is for you to deploy things

Basically it's all fallout from Oracle's "project jigsaw". And it's a huge pain that I'd rather not have to deal with...

a consumer wouldn’t write anything, it’d just build with whatevr jvm they have lein using

not sure why a consumer would be building your project.clj though, but they could

They wouldn't.

But they do need to select which "edition" of my library they wish to consume, to ensure they get the correct upstream dependencies.

So yeah, you use this, and deploy artifacts of the form:

org.mine/some-project 0.1.0-SNAPSHOT-jdk8
org.mine/some-project 0.1.0-SNAPSHOT-jdk10

You can, but those share a pom.

I tested that first, as we discussed last week.

no, built entirely separately

Nope that's not how Maven / Clojars work.

2 different invocations of lein

The second build overwrites the pom of the first.

oh, you are concerned with how to deploy multiple artifacts then

these are classified, could deploy both together and would have classifiers

I can't use classifiers, since I need to build on different JVMs.

And leiningen can't "split" classifiers to run on different JVMs.

but that doesn’t align with what you showed from google doing a similarly hacky classifier deployment based on versions

again, lein runs 2 times

external process

Recall that my dependencies are either included in the JVM (for JVM versions 1.7u6 through 10) or need to be explicitly pulled down (JVM v11+).

So I need two poms./

2 times

LEIN_JAVA_CMD=jvm-x-path lein <task>
LEIN_JAVA_CMD=jvm-y-path lein <task>

each has own everything

completely compile-time built-in due to the eval-syntax of the defproject based on lein jvm

At at the risk of sounding like a broken record, upon deployment to clojars, LEIN_JAVA_CMD=jvm-y-path lein <task> overwrites the POM file that was previously generated by LEIN_JAVA_CMD=jvm-x-path lein <task>.

my snippet above shows how at compile-time the jvm-specific-deps are chosen

So I end up with 1 pom and 2 jars, which is exactly the opposite of what I need.

it depends what you are deploying

if you give them different versions - they aren’t overwriting

Yep

I confirmed it.

I thought as you did, until I tried it out.

And it didn't work.

if you use classifiers - they need to deploy at the same time, because you can’t “overwrite” releases

😉

(in may repo setups)

I can't use classifiers.

Each pom has to be built on a different JVM version, or else the unit tests won't pass.

If you build one JAR, overwriting pom file, and deploy (in the script), then start over with a different JVM version, it shouldn't matter that the pom file gets overwritten after the deploy?

if you call one 1.0-jdk8 and the other 1.0-jdk9 in the <version> of the pom

The poms are different.

you deploy one completely before the 2nd

you showed me that google ended up with a mvn repo structure like

1.0-jdk8/stuff

@mikerod I did exactly that. Perhaps I'm not explaining myself very clearly, but Maven / Clojars elide the "qualifier" on the end of the version string.

if that is the case, it wouldn’t override

So you end up with two poms that "land" in the same directory + file on Clojars.

If you can find any way to do what you want via a sequence of commands from an interactive shell, that produces the correct results, script that.

if it deployed as a real classifier then you couldn’t deploy 2 separate times to the same coordinate

i.e. the second overwrites the first.

@mikerod I can't use classifiers.

ugh

the maven definition of a classifier has some vague semantics around final repo structure

I need each "build" to use a specific JVM version, and classifiers can't be specified to use a particular JVM.

(since leiningen itself is running within a JVM - it can't swap that out at runtime).

you showed me some google repo, that used a “classifier version” structure, but it was actually imposed on the directory structure itself - so it sort of “wasn’t a classifier”, but could be used like one as a mvn coordinate

you have full control on lein’s jvm

as i showed

Correct - to get that out of a single project.clj I need to change the project name.

LEIN_JAVA_CMD=jvm-x-path lein <task>

that uses jvm x

Hence my question this morning.

you could compile-time hard-wire your defproject do about anything based on that

If the project name were a string (as the version is) this would be trivial.

But it's not - it's a symbol.

no reason to mess with project name…

but I may give up here, since not getting a point through

and don’t know the google example you gave before anymore

Yep - that's the only way to influence how Leiningen's underlying Maven machinery determines where to write files during deployment.

Do you have a manual sequence of steps you know how to follow that produces the results you want?

or if you don’t care about version that much, could just pick a naming scheme that doesn’t cause it to “look like a classifier”

Outside of leiningen, you mean?

even if that sequence of steps involves hand-editing the project.clj and/or other files?

Yep.

Let me pseudo code it...

Make a script that does those steps, with instead of "hand-edting one or more files" does sed or any other program to edit those files that you can think of.

1. Select Oracle JVM v1.8 (there are a million ways to do do this, all of them unpleasant) 2. Run unit tests, without the additional dependencies (`lein test`) 3. Build JAR and deploy, without the additional dependencies (`lein deploy clojars`), ensuring the deployed artifacts (BOTH JAR AND POM) have unique GAV coordinates 4. Select Open JDK v11 (there are a million ways to do do this, all of them unpleasant) 5. Run unit tests, with additional dependencies (`lein with-profile +openjfx11 test`) 6. Build JAR and deploy, with additional dependencies (`lein with-profile +openjfx11 deploy clojars`), ensuring the deployed artifacts (BOTH JAR AND POM) have unique GAV coordinates

Could be bash, could be Python, clj, etc. Whatever you are most familiar and comfortable with maintaining.

I don't even need to see what the other steps are, literally. If you can write them as commands in a bash script, Bob's your uncle.

If there are any steps that you don't know how to write as a command in a bash script, please ask -- we can probably figure out a way to do it.

What about my fellow library developers on Windows?

Sorry - that was a mostly rhetorical question.

@deactivateduser10790 who all is building this?

if you need windows support also, for building, then yes, things get more complicated with scripts hah

Yes scripting is always a back door way out. But it's a pretty sucky one imho.

I’ll probably bow-out of trying to fix this issue, since I don’t feel like I’m adding value at this point 😛

but you can hackily change project name for what that’s worth to you

(defproject #=(symbol "foo") ....)

so you could conditional logic, based on jvm or something, the project name if you wanted to

I think lein v3 is even opting to always only go with #= reader dispatch macro instead of the classically used ~, but I have no more details on that. It’s just in a comment I see in the source - https://github.com/technomancy/leiningen/blob/7357010431c926abb559d55b295fe1ba7791ed20/leiningen-core/src/leiningen/core/project.clj#L198

You could write a PowerShell script if you were so inclined (or had a colleague who is)

At times, I consider scripting the unequivocal front door 🙂

There's also LSW

Going off on a tangent for a moment, are there any thoughts around revisiting build tools, especially in light of clojure/tools.deps?

Definitely -- I see it discussed on the #tools-deps channel, and someone there has been publishing and perhaps maintaining a list of tools.deps based tools

I haven't used them myself, so can't help you with what exists vs. what hasn't been developed yet.

FWIW I've played with the lein-tools-deps plugin, and it's fine as far as it goes. The issue comes in that most other leiningen plugins can't use deps expressed in deps.edn.

So stalwarts like lein-ancient become useless, which is a big loss.

I guess I'm just wondering if the consolidation of dependency management by the core Clojure team will sufficiently break the existing build tools that it's a logical point to re-evaluate build tools more generally...

By 'break existing build tools' you mean because some project you want to build via Leiningen doesn't come with a project.clj file? I don't understand "break" there.

I mean "break" in the sense of "these tools can't directly consume deps.edn files yet, and it seems like a substantial effort to add support for that and deprecate their own native dependency management mechanisms (given the ripple effect through the plugin ecosystem etc.)".

Sure, but it is "opt-in" breakage, e.g. moving from major version 1 to version 2 on your own time frame (or not)

Leiningen-specific plans for supporting tools.deps seems best discussed here, but at least lein ancient has a tools.deps-based replacement someone has already developed: https://github.com/RickMoynihan/lein-tools-deps/issues/63