`pom` dependencies lost when using `jar`

[tdavis]

Say I have a task like:

(comp
  (pom :project      'com.example/foo
       :version      "1.0"
       ;; ...
       :dependencies '[[com.example/bar "0.1"]])
  (jar)
  (target))

The pom.xml created by pom includes all the right values, including <dependencies/>. This is confirmed by looking at target/META-INF/maven/com.example/foo/pom.xml. However, the pom.xml included in the JAR has all the right values except <dependencies/>, which lists the default (the dependencies in the Boot environment).

The jar task is clearly picking up on the pom as the resulting file in foo-1.0.jar; without a valid POM it would simply be project.jar. Why are the custom dependencies lost?

Thanks for the amazing build tool!

[Deraen]

What Boot version are you using?

[tdavis]

#http://boot-clj.com
#Tue Sep 20 12:30:29 EDT 2016
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.6.0

[tdavis]

As an aside, I did notice that the dependencies were set properly if I used (task-options! pom ...) in the task rather than rely on passing the options to pom.

[micha]

Interesting, I'll investigate. Thanks for reporting the issue!

[martinklepsch]

A similar situation arises when using the uber task. Currently dependencies are taken from the global env but there might be utility in reading them from a generated pom.xml.

Related discussion w/ @oakes https://gist.github.com/oakes/778de5ca7fd1a764829bcab14a1c42a9

[oakes]

My specific issue is that a few of my projects have tasks that run the cljs task before creating a jar, and I don't want my ClojureScript dependencies to be included in that jar since they are certainly not necessary at that point. For example, the build task for Nightcoders. I experimented with manually setting the :dependencies of the pom task but that didn't affect what went into the final jar. I also tried task-options! as mentioned above but it didn't behave any differently.

[Deraen]

test scope can be used to exclude dependencies from uber task or from being transitive dependencies of a created package: https://github.com/Deraen/saapas/blob/master/build.boot#L36

[oakes]

@Deraen Yes, that is how I currently do it, but this particular issue was spurred by my use of deps.edn (see the first comment on my gist), which doesn't directly support the notion of :scope.