Ok, so in that case why not do the later option I mentioned? i.e. implement a new library rickmoynihan/xml-update that can generate a pom from a previous one (applying command line overrides as necessary). That can then be called in an alias prior to depstar. Strictly speaking it could just do something like assoc-in for any xml file though the main usecase would just be for poms. Alternatively could possibly use xpath or something… though tbh I’d rather the simpler and more familiar assoc-in like semantics.

If you want to fork depstar and do that work, feel free. As I keep saying, I don't plan to do any extensive work on it until tools.build is available and we can all see what it does.

Part of the issue here is that, as you've shown, there are a couple of fundamental limitations to depstar that can't really be solved without adding dependencies, and at least some of those issues will be addressed by tools.build so it would be pointless work, as far as I'm concerned.

Understood. I’m certainly not trying to convince you to waste your time. I’m just wary of waiting for the mythical tools.build. spec and spec2 still aren’t done and its been years.

Splitting depstar into a lib-only and an app-only variant makes it easier to address the limitations -- but, still, even the lib-only form really should deal with the pom.xml stuff (re: rewriting it).

Yeah, though I’m actually proposing: 1. moving the pom updating stuff into its own standalone tool. (I’ve largely done this, just need to package it up etc) 2. eventually maybe extracting the lib stuff from depstar into a lib for building library jars. Or perhaps just building that aspect afresh. depstar may even be sufficient for libs as it stands. 3. depstar over the medium-term potentially refocusses on the uberjarring usecase (depending on how long it takes tools.build to surface. Obviously there are a lot of ifs and buts, and dependencies on people (myself included) actually doing the above, and tools.build may completely obsolete the whole effort; and none of that may happen — but it seems like it might at least be worthwhile agreeing that the direction as outlined would be an improvement for this interim period.

Whether it’s ever actually achieved is another question.

Personally I’d be happy for the three different library pieces to be integrated into a single lib-deps project that covered tweaking the pom, building the jar, and deploying it; but the code would be substantially the same either way.

Currently, depstar addresses my needs for both lib creation (it's how I build all my thin JARs for my projects on http://clojars.org) and for app creation (it's how we build all our AOT'd production JARs at work), so I have no incentive to take on the work you're proposing at this point. Once tools.build comes out, I will reevaluate depstar in that light, especially if someone (you) has already made a "better mousetrap" 🙂

Ok, I’m certainly not expecting you to do anything. I’m largely just asking your opinion on what separation would make the above pieces work marginally better together; given that the community might need to live with compromised solutions for a while yet. I doubt I’ll have the free time to build the better mousetrap, but I can imagine what a more humane one might look like; and maybe implement a few of the required pieces.

Separating depstar into four distinct "tasks" would make sense: sync/transform pom.xml, compile, uber (gathering up artifacts), jar. That's sort of what Leiningen has (although it combines several in its uber task) and it's sort of what Boot had. Because those are build tools. It's what I'd expect from tools.build. But separating those out also means that you need some sort of "temp" folder common to all those tasks. lein and boot have target but depstar avoids that step and can create a JAR file all in one go because of that. So the trade off there is speed -- depstar used to copy everything to a temp folder and then build the JAR from that, but doing it in one step basically doubled the speed.

Each of those tasks would be a lot easier if external dependencies were available to be used but they could still be done with no dependencies. Deployment -- what deps-deploy does -- definitely requires additional dependencies so keeping that physically separate makes sense because its dependencies are very different to what depstar needs.

Performing ${var} substitution on pom.xml in depstar would be a worthwhile enhancement, at the expense of yet more complicated command-line invocation -- unless we go "all-in" on -X style invocation and accept that exec.jar will end up in the uberjar.

exec.jar being in the uberjar probably isn’t the end of the world, unless folk are calling the uberjar itself via clojure -X

(`exec.jar` is not an issue for thin JAR building, which would still benefit from pom-transforming)

Also, switching to -X style invocation and only supporting ${var} substitution in that mode means the existing command-line arg processing can be left alone (or even deprecated).

Yeah I was thinking it would be worth deprecating the cli stuff -X invocation is far superior

I've done that with clj-new but stopped short with depstar only because of t.d.a getting included in the uberjar (which got fixed; although we still get exec.jar).