Is tools.build considering adding a :license argument?

Question

Now that Clojars requires licenses, projects that need to go up there need a license block in the pom files of their jars. Using build.tools it's possible to create a pom.xml, manually edit it to include a license section, then create a jar using that pom. But, that's manual.

Are there plans to add an option for write-pom (and gen-pom) to allow programmatic insertion of a license?

Comments

I think this is a good idea. write-pom already has option to add SCM information. For many projects, a pom.xml only used as a template is a) redundant b) adds complexity and c) may be misinterpreted by those new to Clojure or by automated tools, unless put under a redundant subdirectory (e.g. template).

---

FWIW this was (one of) the original impetuses for this project: https://github.com/pmonks/tools-pom

Answer 1

tools.build v0.9.6 now includes an additional :pom-data attribute that can be used to provide license (and any other pom data) in hiccup style to put in the generated pom.

Docs: https://clojure.github.io/tools.build/clojure.tools.build.api.html#var-write-pom

Example:

(b/write-pom
  ...
  :pom-data 
    [[:licenses
      [:license
        [:name "Eclipse Public License 1.0"]
        [:url "https://opensource.org/license/epl-1-0/";]
        [:distribution "repo"]]]]) 

Comments

I've already switched my OSS projects over to use this and it works great! Thank you!

And I updated deps-new so the projects it generates all use this too, instead of a "template" pom.xml file. So much nicer!

Answer 2

write-pom can already use a "template" pom.xml file to produce the final, uploaded pom.xml file. That's what deps-new and clj-new generate -- see the source of that template file:

https://github.com/seancorfield/deps-new/blob/develop/resources/org/corfield/new/lib/root/template/pom.xml

That's also how I deal with this in my FOSS projects, like next.jdbc:

https://github.com/seancorfield/next-jdbc/blob/develop/template/pom.xml

and:

https://github.com/seancorfield/next-jdbc/blob/develop/build.clj#L45

I don't think tools.build should add a :license option -- there are plenty of other fields that "should" be in an uploaded pom.xml file that write-pom also omits, and the :src-pom option lets you provide all of those.

I do think more documentation could recommend the use of a "template" pom.xml file (and I'll update the clojure-doc.org cookbook for tools.build to reflect this).

Comments

clojure-doc.org issue: https://github.com/clojure-doc/clojure-doc.github.io/issues/59

deps-new issue (to move "template" pom.xml from root to a template folder): https://github.com/seancorfield/deps-new/issues/45

---

I was referring to the template when I said "… then create a jar using that pom".

(I have not manually run `jar cf` in many years, and plan to keep it that way)

I guess I only needed a tiny pom.xml, rather than generating the whole thing with `-Spom` since so much of the file gets replaced.

I still prefer programmatic access to building the pom, but I can see the argument for the template, despite disagreeing with it.

---

I think a note about this (licenses specifically) in the write-pom docstring and in the tools.build guide would help a lot too.

---

clojure-doc.org now has this new section: https://clojure-doc.org/articles/cookbooks/cli_build_projects/#the-generated-pomxml-file

---

If you use b/write-pom programmatically that's quite cumbersome to have to rely on templates. It's also asking *every* lib deployed on Clojars to do that.

The addition to t.build seems also quite minimal to support this (our fork does this: https://github.com/clojure/tools.build/commit/df75a6c3f9d2297f27da572836d004fd66b8d894).

---

It just seems a bit "slippery slope": first we got :scm as a hash map, then maybe add :licenses as a vector of hash maps, then some other options for other XML fragments folks think are important to add... It's going to make for an entire DSL just in options!

There has to be a better way. I think adding :scm was a mistake, TBH.

How about an inline template as a single hiccup-like structure? Just one option, it's data, it can support _any_ pieces of the XML file that folks want to generate...