depstar 2.0-in-progress now supports :compile-ns to specify a vector of namespaces to compile even for (thin) JAR files -- someone was asking for that feature a while back (sorry, I don't remember who). I've also added support for :compile-ns :all 🙂

I'm continuing to work on depstar (since I'm off work today -- having GitHub sponsorship is more motivating than I would have imagined 😉 ) and I'm looking at the implications of being able to override group, artifact, and/or version when you build a JAR file. Since you may well be building a library for deployment, it seems likely that the pom.xml file used for the JAR will also be the pom.xml file used for the deploy which means that you'll want it to match: so what goes into the JAR and what goes up to Clojars etc should be the same. In addition, if you have a VCS <tag> in your pom.xml, it's probably going to be the same as the <version> with just v in front of it (maybe? that seems to be the most common convention?). So it seems that if you override any of :group-id, :artifact-id, or :version, you would need depstar to actually update your pom.xml file so that any deploy step also gets the same group/artifact and version. How do folks feel about depstar updating the pom.xml file if you specify overridden values for any of those three fields?

Now that depstar will be working as a "tool" (with :replace-deps), it is depending on tools.deps.alpha (and a few other things) so it could also invoke the equivalent of the CLI's -Spom operation to create/sync pom.xml based on deps.edn. It looks fairly straightforward but I'm not sure how stable that aspect of the t.d.a API is. Would that be something that folks would like depstar to be able to do automatically for you? [The danger here is that depstar would be complecting functional steps that should probably be kept separate, but these are opt-in operations: if you don't override the group/artifact or version, it wouldn't update pom.xml and the auto-create/sync would also be opt-in]

https://github.com/seancorfield/depstar/issues/54 if folks want to offer opinions.

Alex said that sync-pom API was "relatively stable" so I've gone ahead and implemented a :sync-pom true option that runs the equivalent of clojure -Spom but using the same calculated project basis that depstar uses to build the JAR file (so it respects :repro true/false and any :aliases you specify).

After lunch, I'll revisit the awful log4j2 plugins cache file stuff...