Meyvn
Know your build

Copy and paste the following command in your terminal:

clj -Sdeps '{:deps {org.meyvn/meyvn-installer {:mvn/version "1.5.1"}}}' -M -m meyvn-installer.core

• Download Meyvn to your local repository

mvn org.apache.maven.plugins:maven-dependency-plugin:3.2.0:get -DremoteRepositories=https://nexus.tuppu.net/repository/meyvn/ -Dartifact=org.meyvn:meyvn:1.7.4

• Create a new shell script in your path.

$ touch /usr/local/bin/myvn

• Edit your newly created shell script with the following.

$ cat /usr/local/bin/myvn
#!/bin/sh
M2_HOME=/path/to/maven/root java -jar ~/.m2/repository/org/meyvn/meyvn/1.7.4/meyvn-1.7.4.jar "$@"

M2_HOME points to the root of your Maven installation directory, replace the content with the prefix appropriate for your system.

Note: Maven can run without this environment variable on the command line, but the Maven Invoker APIs require it to be set explicitly.

• To find the prefix for the Maven installation on your system.

$ readlink -f `which mvn` | awk '{gsub("bin/mvn", ""); print}'

Note: On Mac OS X, brew install coreutils and replace readlink with greadlink.

• Set the executable bit.

Note: $@ references the arguments passed to the script.

$ chmod +x /usr/local/bin/myvn

Note: Some features require access credentials

Add your Meyvn credentials to your settings.xml file in /.m2 repository.

  <server>
  <id>meyvn</id>
  <username>yourname</username>
  <password>yourpassword</password>
</server>

Consider the following deps.edn file:

{:paths ["src/clj"]
 :deps {org.clojure/core.async {:mvn/version "0.4.474"}
        ring {:mvn/version "1.6.3"}
        compojure {:mvn/version "1.6.1"}}
 :aliases {:cljs {:extra-deps {org.clojure/clojurescript {:mvn/version "1.10.238"}
                               reagent {:mvn/version "0.8.1"} 
                               secretary {:mvn/version "1.2.3"}}
                  :extra-paths ["src/cljs"]}}}

The Clojurescript-side of the mixed project is cleanly segregated. The :cljs alias is used when compiling the *.cljs files, but not when assembling the uberjar, helping to keep the latter small. You tell Meyvn to use this alias in the meyvn.edn configuration, under the cljs -> tools-deps-alias keys.

If there is a resources folder in the base directory, it will be included in the build.

Meyvn uses the Apache Maven Shade Plugin in order to build uberjars.

Shading dependencies is the process of including and renaming dependencies (thus relocating the classes & rewriting affected bytecode & resources) to create a private copy that you bundle alongside your own code. But the shading part is actually optional: the plugin allows to include dependencies in your jar (fat jar), and optionally rename (shade) dependencies.

Meyvn gives you access to the exclusions facility provided by the Shade plugin, equivalent to Leiningen’s uberjar-exclusions or Boot’s standard-jar-exclusions.

:excludes {:artifacts ["org.clojure:google-closure-library"]
           :filters ["META-INF/*.MF" "META-INF/*.SF" "META-INF/*.DSA" "META-INF/*.RSA"]}

Note that you don’t need to exclude INDEX/LIST as this is built-in by the Shade plugin.

Additionally, Meyvn allows you to exclude artifacts. For example, sometimes the Closure library is pulled by a transitive dependency and lands in your final uberjar. With Meyvn you can prevent that.

Data readers are merged with a custom transformer that knows how to merge EDN maps.

Libraries uploaded to Clojars are typically non-aot, source-only jars. Uploading to Clojars follows standard procedure. Private repositories are supported as well. For example, to upload an artifact to deps.co, adjust the remote repository setting in the jar section of meyvn.edn.

:distribution-management {:id "deps"
                          :url "https://repo.deps.co/your-org/releases"

In all cases, use settings.xml for storing your credentials, or refer to Maven for password encryption.

Meyvn works with its own set of pom files. It isn’t bothered with existing pom files in your project directory. This is by design. The single source of truth is deps.edn. Together with the configuration (in meyvn.edn), it knows all that it needs to know.

The added benefit is that you can continue to maintain a pom file if you are already using a Maven workflow.

The transitive dependency mechanism used by Maven is guided by the nearest wins conflict resolution strategy. This allows for resolution of individual conflicts: for any particular conflicting dependency, you can specify its version within your own POM, and that version becomes the nearest.

Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.8 it was not defined which one would win, but since Maven 2.0.9 it's the order in the declaration that counts: the first declaration wins.

You can use dependency convergence, forcing the build to fail on transitive dependencies that are not on the same version.

Consider the following deps.edn file.

{:paths ["src"]
 :deps {
   clj-time {:mvn/version "0.14.2"}
 }
 :aliases {:test {:extra-paths ["test"]
                  :extra-deps {org.clojure/test.check {:mvn/version "0.9.0"}}}}}

Again, please note the best practice of segregating paths and dependencies with aliases. To run your tests with Meyvn, make sure the relevant section in meyvn.edn looks like this:

:testing {:enabled true
          :tools-deps-alias :test}

Then run:

$ myvn clojure:test

The build will abort in case of errors.

$ myvn -a nrepl

This will start a nREPL server with Cider middleware that you can connect to with nREPL clients.

In Maven, profiles are used to parameterize builds, not the runtime environment of the executable. There are good reasons for this, but this means that after your build is done, you can't just run the executable (if it needs environment variables to be set). First you need to make sure the environment is set up properly.

Meyvn can help with that. When you enable the profiles section, Meyvn will create a Maven profile in the transient POM, and under each profile (for example, staging or production), it will write a standard edn map describing your environment into standard java properties.

(We leverage the fact that custom properties can be defined under any profile.)

On your staging/production server, those properties will be accessible in the pom alongside your jar in the local repository.

Meyvn doesn't want to force you to install clojure or Meyvn on your servers, but if you do, you can use it to list those properties and pipe into a script in typical UNIX style.

$ myvn -x list -a org.bar:foo:1.0.0 -p production

The -a switch is for artifact (in Maven coordinates) and -p is for profile.

The script could, typically, massage the properties into environment variables. How you use them depends on your final command output, really. The last mile is context-dependent.

In the absence of Meyvn on the server, you can get the properties via the Maven helper plugin.

$ mvn org.apache.maven.plugins:maven-help-plugin:3.1.0:all-profiles "-Dartifact=org.company:myproject:1.0.0

$ mvn org.apache.maven.plugins:maven-help-plugin:3.1.0:evaluate -Dexpression=project.properties -Dartifact=org.company:myproject:1.0.0

Finally, Meyvn has built-in support for runit, the UNIX init scheme with service supervision. The following command will write the environment in the format expected by runit under the path specified by the -t argument.

#+BEGIN_SRC sh myvn -x write -a org.bar:foo:1.0.0 -p production -t /opt/foo #+END_SRC sh

Meyvn runs with the same interface as Maven. Goals and lifecycle phases are being passed to it as you would with standard Maven. The -x flag changes the mode of operation and allows you to run specialized tasks.

Simply run myvn -x to see what is available. Currently, Meyvn can generate the POM file, list newer versions of dependencies, show platform information. More functionality is to be expected.