From c4e9477f2a5b1f774931f6729a5f4f4320f5c326 Mon Sep 17 00:00:00 2001 From: Alex Miller Date: Thu, 11 Nov 2021 13:43:03 -0600 Subject: [PATCH] add info on how to run an uberjar built with tools.build in the guide, #561 --- content/guides/tools_build.adoc | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/content/guides/tools_build.adoc b/content/guides/tools_build.adoc index 6a7b29f6..04e7b13c 100644 --- a/content/guides/tools_build.adoc +++ b/content/guides/tools_build.adoc @@ -140,18 +140,26 @@ When preparing an application, it is common to compile the full app + libs and a :class-dir class-dir}) (b/uber {:class-dir class-dir :uber-file uber-file - :basis basis})) + :basis basis + :main my.lib.main})) ---- The deps.edn and build execution will look the same as the prior example. You can create the uber jar build with: -[source,clojure] +[source] ---- clj -T:build uber ---- +The output of this build will be an uberjar at `target/lib1-1.2.100-standalone.jar`. That jar contains both a compiled version of this project and all of its dependencies. The uberjar will have a manifest referring to the `my.lib.main` namespaces (which should have a `-main` method) and can be invoked like this: + +[source] +---- +java -jar target/lib1-1.2.100-standalone.jar +---- + == Parameterized builds In the builds above we did not parameterize any aspect of the build, just chose which functions to call. You may find that it's useful to parameterize your builds to differentiate dev/qa/prod, or version, or some other factor. To account for function chaining at the command line, it is advisable to establish the common set of parameters to use across your build functions and have each function pass the parameters along.