This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (12)
- # babashka (42)
- # beginners (45)
- # calva (60)
- # cider (6)
- # circleci (1)
- # clj-kondo (18)
- # clojure (21)
- # clojurescript (36)
- # conjure (13)
- # cursive (2)
- # datahike (5)
- # datomic (4)
- # depstar (17)
- # emacs (4)
- # fulcro (3)
- # honeysql (2)
- # jobs (2)
- # jobs-discuss (9)
- # lsp (98)
- # malli (32)
- # off-topic (36)
- # other-languages (2)
- # overtone (4)
- # re-frame (5)
- # reveal (7)
- # rewrite-clj (47)
- # shadow-cljs (25)
- # spacemacs (4)
- # vim (7)
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
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:
For “common” cases,what else is needed? Some sections that are missing from autogenerated poms include:
<packaging> <groupId> <artifactId> <version> <name> <dependencies> <build> with <sourceDirectory> <repositories>
What else is missing/needed? Most of those could be filled in with relatively static data/strings contained in
<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.xmlcould be specified as a starting place for the pom update, and that the resulting pom would have a different file name, eg
pom.xmlor whatever is specified by
:pom-fileso 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….
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
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.
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.