I have a “philosophical” question/proposal regarding depstar and pom.xml files: If we can generate a pom file automatically from information contained within deps.edn and the SCM/VCS environment of a project, then we should, and if so, then there is no need for a project to maintain a pom.xml One retort I received was along the lines of “maven and pom have way too many features, and why should Clojure tool devs try and deal with all that”, which is a good/reasonable point, but I wonder of this might be a case where we could solve (easily) this for 90% of projects, and for others, maintain the existing mechanism of using depstar to modify the existing pom, to handle the cases where pom/maven features are needed that are not expressible via deps.edn. I am no expert on on maven/pom, so maybe I am way off base here, but it seems like this might be doable with relatively small/moderate changes to existing tools, depstar specifically. ATM, depstar (in combination with clojure -Spom) generates a pom containing:

<packaging>
<groupId>
<artifactId>
<version>
<name>
<dependencies>
<build> with <sourceDirectory>
<repositories>

<description>
<url>
<licenses>
<developers>
<scm>
<distributionManagement>

depstar doesn't need a pom.xml at all (now -- it used to).

You as a developer need a pom.xml file to deploy to Maven or Clojars.

http://cljdoc.org uses pom.xml (from inside the JAR I believe?) to figure out how to find the GitHub source and docs and which git SHA or tag or whatever to use to generate the docs.

clj-new includes a full-fledged pom.xml template that works with Maven/Clojars and http://cljdoc.org.

When you depend on an artifact on Maven/Clojars, that dependency needs the pom.xml flie. When you depend on a local or git dep, tools.deps.alpha needs either deps.edn or pom.xml.

@dcj I've no idea what you think needs to be depstar regarding pom.xml?

(sorry if I am just missing something in what you posted above?)

To be specific: Enhance despstar to support generating additional pom "stanzas" (e,g, description, url, licenses., developers, distributionManagment, and scm) via exec-args data. Most of those stanzas are populated with relatively static text, so super easy. The scm stanza contains tag and filling that in requires accessing that info from the SCM system, depstar does this today elsewhere in order to fill in the same info in pom.properties so should be straightforward to implement.

@dcj quite a bit of that is already in clj-new which seems to be the better place for it.

OK, I will take a look at that.

As I said, depstar itself does not need pom.xml.

clj-new has a generator system which is designed for updating files.

AFAICT, What I am failing to communicate is the/my goal that in many/most cases pom.xml should be generated (in its entirety) when needed, and if that can be done, there is no need to have a distinct pom.xml in one's project repo, just generate it when you need it

Generate it when needed using depstar, info/data within deps.edn, and info obtained from the state of the SCM

If that is a bad/unnecessary/infeasible goal, then no need to discuss the implementation details 🙂