Clojurians Log v2

That’s a use case this library was developed for: https://github.com/pmonks/tools-pom

Yeah - I made a similar PR last year: https://github.com/slipset/deps-deploy/pull/21 but it predates tools.build, so would want to be rethought now

Given that the source template for the pom.xml file doesn't need to be called pom.xml, and can be very minimal -- just containing the specific non-default bits of data you want -- I think it's reasonable to have that under version control, just like you have any other "config/control" files under version control (`deps.edn`, your build.clj file etc). It seems weird to me to talk about "forking tools.build" because of that, unless I'm misunderstanding your comment @weavejester?

@seancorfield the problem with that is that those minimal / incomplete pom.xml files confuse other Maven-based tooling.

(including GitHub itself, for example, when it tries to do its dependabot security scanning)

@dcj your framing absolutely resonates with me, and I threw this together to scratch my own itch on this problem: https://github.com/pmonks/tools-pom I’d greatly appreciate your thoughts (especially on the general approach - the code itself is a bit of a rush job though…).

@deactivateduser10790 That's why I made a point of saying they do not need to be called pom.xml!

Sure, but defaults have inertia.

That is exactly a concern someone has raised and has been discussing on Discljord Discord server. IIUC, a library author might not care about the default and be completely fine with a template pom.xml lingering at the rood. But a library consumer will have potential problems if their tooling decides to look at that file.

No need to throw the baby out with the bathwater. build.clj can just specify :src-pom and you can call the file pom_template.xml or whatever you want. Heck, you could even have build.clj copy the generated file back to the root of the project instead so that the complete, correct pom.xml is at the root, can be checked into git, and can be relied on by other tooling. The choice is entirely up to you.

Complaining about defaults and inertia when you have full control over this is silly.

You as a library author have full control over where pom.xml goes - yes. You as a library consumer have full control iff you fork the library. If the author of the library has used the default pom.xml at the root of the project as a template, then all your tooling that knows about pom.xml files will be screwed. Or am I misunderstanding something?

If the project has a pom.xml and it is out of date and negatively affects tooling, that's a bug. Create an issue and get the library owner to fix it.

That's what you'd do if tools.build wasn't even in the mix, right?

Consumers of the library are generally going to be depending on the pom.xml inside the JAR tho', right?

The pom.xml that is uploaded to Clojars, for example, should be the complete, generated one. That's what should be passed to deps-deploy for example.

Generally - yes. But not in all cases. It's about applying my tools to someone else's code. Not a JAR. Not a Git dep. The code.

Then raise an issue and get the library author to fix it. It's a bug, plain and simple.

Either don't have pom.xml or have a correct one.

Indeed! That's exactly the point - a template pom.xml a priori is not correct by itself. But the default template path is exactly pom.xml. So it's a bug affordance.

Then complain on http://ask.clojure.org and see if you can persuade the core team to change that?

I think the burden is on the library author, personally, but you don't agree.

Then the tool imposes the burden on library authors. :) My main intention here was to figure out if I understand the situation correctly, and seems like it's the case now. Someone that actually uses template POM files and happens to have an alternative approach in mind would be in a much better position to create an question.

@p-himik In the mean time... https://github.com/seancorfield/build-clj#pomxml-and-jar

Oh, the irony! So I decided to follow that advice and rename pom.xml to pom_template.xml and now the GitHub Actions setup_java fails because it requires that your repo includes a pom.xml 😞

Updated that section to suggest template/pom.xml -- which satisfies GitHub Actions' setup_java and still avoids having an (incomplete and/or outdated) pom.xml in the project root.

@seancorfield that may be something else. I have a project (several in fact) that use the setup-java GitHub Action, but do not include a pom.xml anywhere in the checked in code, and that seems to be working fine. Here’s an amusingly meta example of that: • Project: https://github.com/pmonks/tools-pom • Use of setup-java: https://github.com/pmonks/tools-pom/blob/main/.github/workflows/deploy.yml#L18 • Confirmation that this repo does not include a pom.xml anywhere: https://github.com/pmonks/tools-pom/search?q=pom.xml (observe that none of the search results are for a file called pom.xml).

I was surprised by it. Are you using v1 or v2? I see you're using v2, same as me.

Oh, you're not enabling the maven cache so that's probably it.

https://github.com/seancorfield/next-jdbc/blob/develop/.github/workflows/test-and-snapshot.yml#L10-L14

Ah yes well spotted. I’d been wondering about enabling that on the off chance it might help with tools.build builds, but this finding suggests that that might not work. 😉

Well, it does help since it caches the ~/.m2/repo stuff between builds so you don't have to "download the world" for each build, so your tests/builds run faster. But you need a pom.xml somewhere -- in my repos, it's template/pom.xml which satisfies the GH setup and provides cache from run-to-run -- and still lets me have a :src-pom for write-pom without needing a misleading pom.xml in the project root.

Now, I suspect the cache is only recalculated if that template/pom.xml changes so if I update deps.edn, it will have to download any new deps but that's still better than no cache (since the cache will also include all the tools.deps stuff as well which doesn't change very often).

Yeah I was leaning more towards using the https://github.com/marketplace/actions/cache directly, since that lets one specify file paths (which could include both ~/.m2/repository and ~/.gitlibs/libs ), and doesn’t require a pom.xml or whatever (it’s also what the Maven caching mechanism uses under the hood). Obviously what would be even better would be a comprehensive tools.build based GitHub Action that just rolled all this stuff up, but I’m currently 2 side projects away from my primary development priority, so probably can’t justify biting that off just yet. 😉

Yeah, that cache action is more like what I am using in BitBucket Pipelines where I cache those two and also ~/.clojure and ~/.cpcache which also avoids classpath recomputation in the CLI etc.

I want/feel that pom.xml is a generated "artifact" and I'd prefer not to have a template at all. I'd prefer if everything needed for most pom.xml files be generated from other sources of truth. deps.edn is one potential source of truth, and earlier this year I worked with @seancorfield (`depstar`) and created a PR for deps-deploy to support centralizing and abstracting various aspects, enabling a deps.edn like this (for example):

:mvn/repos {"acn-snapshots" {:url ""}
             "acn-releases"  {:url ""}}

 :aliases
 {:mvn/artifact-id database
  :mvn/group-id    org.aircraft-noise
  :mvn/version     "0.3.4-SNAPSHOT"
  :jar/file-name   "database.jar"

  :jar {:replace-deps
        {com.github.seancorfield/depstar {:mvn/version "2.0.216"}}
        :exec-fn hf.depstar/jar
        :exec-args {:jar         :jar/file-name
                    :artifact-id :mvn/artifact-id
                    :group-id    :mvn/group-id
                    :version     :mvn/version
                    :sync-pom    true}}

  :deploy {:extra-deps {com.dcj/deps-deploy
                        {:git/url ""
                         :sha "cf0f5e612eab04789c757a98f544eb8dea61a45b"}}
           :exec-fn deps-deploy.deps-deploy/deploy
           :exec-args {:installer :remote
                       :sign-releases? false
                       :artifact :jar/file-name
                       :repository "acn-snapshots"}}
  }

Here you go: https://github.com/pmonks/tools-pom

It did cross my mind…

I was slightly surprised, without understanding all the hard work that went into making the decision, that while tools deps source of truth is declarative, tools build source of truth is programmatic.

I understand the reasoning behind it. I think a project.edn would only make sense if you could pick and choose the “build library” that goes along with it.

And I guess there's really nothing stopping anybody from rolling their own build truth stored in a project.edn while using tools build.

Also seems like a viable option

Thanks. Will check it out...

It's actually a single word. there is no dash or underscore in the project/folder names.

ok that's definitely not it then. perhaps you can make a public repository with a repro

random guess, it might be this issue: https://github.com/clj-easy/graal-build-time/blob/main/build.clj#L1

Thanks but I'm using shadow-cljs for cljs builds. This only applies if I'm using tools.build for the cljs builds too, right?

No this is just the clojurescript compiler. Which shadow uses as well. I’m sure it will work there as well