Maven

[jburel]

Add template to build using Maven
This has been tested in the BF repo see https://github.com/jburel/bioformats/actions/runs/370615843

[sbesson]

One immediate suggestion to add pom.xml to the JSON description.

Tested in a few context of a few repositories.

• [minimal-omero-client](https://github.com/ome/minimal-omero-client/actions/runs/381054924(
• bio-formats-examples
• ome-codecs

Other repositories will need extra customizations:

• ome-common-java requires infrastructure to run the S3 tests on some platforms
• ome-model has some Python requirements

A related question is whether you see the Maven deployment happening as part of this template or in a separate template running on tags like PyPI? For reference, we have 2 strategies depending on the target repository:

• for OME Artifactory deployment, a deploy phase was following the Travis build phases and running mvn deploy with a secret
• for OSS Sonatype deployments, the process was carried out manually with the signed GPG key

[jburel]

I think we should split the "deployment" step and the "build" from the template.
Some packages e.g. minimal-omero-client do not need the deployment step.

[jburel]

Some repos won't be able to use the template as such. The same is true for the gradle template e.g. https://github.com/ome/omero-blitz

[joshmoore]

I think we should split the "deployment" step and the "build" from the template.

If the one workflow won't be a single solution, then might be worth renaming. Have we split the two procedures in the other ecosystems as well?

[jburel]

Gradle for example does not have yet any deployment
Publishing to several locations (as we discussed) e.g. artifactory/ sonatype/github. This could make the template a bit convoluted and might not work depending on the actions used. Combining the various locations is more my reasoning for splitting.
The Maven template could have the recommended deployment whatever it is

[sbesson]

Summarizing briefly a conversation with @jburel:

• for Python, the Tox-based workflow is certainly different from the deployment workflow. This is largely motivated by the fact different build targets are used i.e. install vs sdist/bdist_wheel
• for Maven projects however, the deploy target is at the end of the Maven lifecyle so a separate deployment job would re-execute most of the steps of the build job. From my side both a combined multi-step workflow as well as separate build vs publication workflows are conceivable and have advantages and trade-offs.
• assuming separate workflows, what would be the name of the publication worklfow? publish_maven? maven_deploy? publish_{artifactory,ossrh}?
• similar decisions will likely be made for Gradle-based Java projects

[jburel]

One option could be to have a flag at the top of the template indicating the desired deployment target e.g. push artifact to GH
push artifact to artifactory, ossh.

[jburel]

I will list this for review since some repositories that do not need deployment steps could benefit from that template as it is

[jburel]

tested the GH publishing option in ome/omero-downloader#46

[sbesson]

Think this is a great start. Understanding this template might be expanded to cover publication release steps - see ome/omero-downloader#46, happy to get this merged it and start apply it to the relevant repositories. The main disadvantage is that it might involve a wave of workflow updates. @joshmoore any concern or additional thoughts?

[joshmoore]

Nope, none as it stands. I can see getting this in a propagating or trying to get the uploading handled to only need to rollout once.

[sbesson]

Understood, immediately I'll start rolling this out to the Maven repositories deployed on OSSRH since there was no equivalent and we still need to investigate this publishing strategy.