Clojurians Log v2
depstar
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>deps.edn.
The `<tag>` within <scm> needs information from the current SCM/VCS environment, and depstar does this when generating pom.properties, so leveraging that code seems possible.
In the case that a project needed to provide a more extensive pom “template” that would be updated by depstar, then it might be nice if this pom-template.xml could be specified as a starting place for the pom update, and that the resulting pom would have a different file name, eg pom.xml or whatever is specified by :pom-file so the pom-template would likely be checked into the project, but not the generated pom.
What do people think?
Is this a terrible idea? (would not be the first time for me!)
What am I missing?
If there was interest/support, I’d be happy to write the code as a PR….
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
FWIW I’m a bit late to this conversation, but I 100% agree with you. deps.edn files today are already being “stuffed” with additional elements that the core tools.deps code doesn’t understand / read, and I see no reason why that approach can’t be extended to provide all of the elements a comprehensive pom.xml generator would need. I would also vastly prefer not to have a partial pom.xml file sitting in my checked in code - it’s incidental complexity that confuses some newcomers / casual perusers of my projects, as well as some tooling.
If that is a bad/unnecessary/infeasible goal, then no need to discuss the implementation details 🙂