Add a pom generation option to the release task

[jgrodziski]

For open source project it is useful to have a pom.xml file along the deps.edn to facilitate the upload to maven repository like clojars. Generating the pom with the proper version and commit it during the release process would be a useful option.
The task can rely on the code from clojure.tools.deps.alpha.gen.pom namespace in tools.deps.alpha.

[JeremS]

Hey Jérémie,

As I told you before I was playing with the idea of using metav to drive build tasks. I have made some experiments and one way to do it would be using badigeon.

I created a branch in which I started adding a pom generation & update operation. I added the function metav.api/sync-pom!, which uses code from the new ns metav.domain.deps.

We could drive the creation of jars, wars,... with the naming of artefact based on metav's naming scheme this way.

Cheers,

Jeremy.

[jgrodziski]

Hey great! didn't expect a code contribution as soon :)
Seems that the badigeon.pom namespace borrows code from clojure.tools.deps.alpha.gen.pom namespace except the make-pom-properties function.
It's better if we could minimize the number of dependencies of metav.

[JeremS]

Hi,

I agree it's a trade-off pulling badigeon in as a dependency. I am not impartial however, I like the project and a lot of the code we might want dealing with tools deps is already there.

Pom.xml generation is there, as are jar/uberjar/war generation. It also has the necessary code for maven install & deploy. It handles classpath generation with deps aliases which could be useful for native images compilations.

It depends on what we want the scope of metav to be. If adding a pom file is the end of it, pulling badigeon in is overkill and opens the disadvantages of having another dependency. If we'd like the release operation to propose maven install&deploy on top of git pushes, not including badigeon would mean redoing work that's already done.

Another way of doing it might also be to have metav's context api being closed in the way that an hypothetical metav-core project would concern itself only with providing project naming, versioning and version bumping based git state. Spitting metadata, generating a pom, tagging a commit with a new version, pushing that commit or generating a jar and deploying it on a maven repo could be done in different projects all using that core. That idea however also has its own set of trade-offs attached to it...

I hope you don't mind me throwing out ideas, It comes back to what scope is metav to have. I clearly wanna base a build process on it, but it may be a very bad idea to have all that functionnality in metav itself.

Cheers,

Jeremy

[jgrodziski]

Hi Jeremy,

I would say that the purpose of Metav is to handle git and version related metadata.
Pom generation is maybe an improper way of naming the requirement: set the version found in pom.xml file to be managed by Metav because we need consistency between the git state and the pom.xml state. I would set the responsibility of pushing any artifact (docker image, jar, etc.) to other components, triggered by any CI/CD platform.
I agree with you, there are three group of features in Metav:

• version management features (display, bump, etc.)
• spitting version metadata somewhere (pom, resource/source file, etc)
• git synchronization stuff (tag, push)
  Maybe the code should more clearly reflect these three parts.

I like the idea of a build tool using pure Clojure code and tools.deps, with a common behavior of API's function to take and return a context as a map. It's simpler than Ring-like middleware of Boot, with pre and post task, etc. We have all the tools available in pure Clojure code.

So I prefer Metav to stay a narrow tool focused on version management and to shift all other build related features to another project (Badigeon or something else).