Welcome! Please see the About page for a little more info on how this works.

+1 vote
in tools.build by
retagged by

I am developing a library with a dependency on tools.build and I would like to publish it as a jar. Whilst tools.build is only available as a git dep, I cannot include it as a dependency in my pom file. A wider discussion on this topic was held on this slack thread, where @alexmiller requested that I raise this topic here.

2 Answers

+2 votes
I'm not sure this is the right issue?
Yep, sorry, grabbed the wrong url
0 votes

In addition to Alex's use case of building on top of tools.build, there are other reasons a .jar can be useful.

Exact reproducibility is another reason to consider this. If someone wants to build a product used in avionics in the US, they'll need to be compliant with the FAA's DO-178C... I'm not a lawyer, but my understanding is one requirement is the ability to produce binary-exact duplicates of software deployed to a device for the lifetime of the device, that can be several years after they're approved. I don't do this kind of work myself, but I do things that support such folks. Minor changes to tools like clojure or tools.build can have effects on what exact code is produced/executed, how many instructions are performed, how much memory is allocated, etc. In situations like this, even the most minor backwards-compatible changes can't be tolerated. Other fields like robotics or satellites can have similar reproducibility requirements, and I suspect the US is not the only country with this kind of regulation.

A maven coordinate is a more-immutable thing, and has a better track record over the time to get you exactly-the-same artifacts.

Exact git commits are reliable (and probably a best option for most projects), but git histories can be revised or deleted... Git "releases" are even more mutable. They can be moved around (e.g. github to gitlab) and also tags can be moved. These are scarier ideas if you're trying to think 5 or 10 years in the future, where project maintainers may have changed a time or two.

Clojure already does not have reproducible builds in terms of compiled code, so a JAR of tools.build is irrelevant to that issue. If the requirement is a "binary-exact duplicate" then Clojure is excluded.
It didn't sound like binary exact reproducibility from source, but for deployment. The Jar once built is always going to be the same (even if it just contains Clojure source).

That said, I'm curious, what about Clojure builds is not reproducible from source? I know a Jar isn't, because of metadata like timestamps on files and all, but that can be stripped, and the content of the Jar would still be reproducible.
Looks like it has been done! Thanks all! https://search.maven.org/artifact/org.clojure/tools.build/0.8.4/jar

> Clojure already does not have reproducible builds in terms of compiled code

I think a specific version of Clojure applied to the same source code will always generate the same output. (Unless someone is introducing time/random seed in the compilation tasks?)

> I'm curious, what about Clojure builds is not reproducible from source?

Well, me too, honestly. But all said, if we have an immutable asset we can point to, we have reduced the set of things that can introduce nondeterminism.