Deploy pre-built SNAPSHOT pre-release (dev, unstable) versions of Engine and DataCapture to a Maven repo

[icrc-fdeniger]

Is your feature request related to a problem? Please describe. Would like to test easily last development in an Android App based on Open Health Stack

Describe the solution you'd like a SNAPSHOT version is deployed after a push to main branches.

Describe alternatives you've considered Build locally the jar.

Would you like to work on the issue? Tried to find more info on github actions and how jar are currently deployed but didn't find it. Can work on the solution

[santosh-pingle]

@vorburger what are your thoughts on it?

[vorburger]

@santosh-pingle if I understand this correctly, I think this is a good idea!

@icrc-fdeniger which Maven repo would you expect to find such -SNAPSHOT JARs on? Pushing them to "Maven Central" (i.e. https://repo1.maven.org/maven2/) is more "involved" (complex) than publishing Maven artifacts to GitHub Packages - that should be easier. The only drawback of the latter that I can think of that you would need to add https://maven.pkg.github.com/google/android-fhir/... to the Gradle configuration for Maven repos of your project. (And if your organization uses "internal Maven mirrors", there is some more additional work to "proxy" this correctly.)

Also, it goes without a saying that this is "unstable". Your internal builds can break from one day to another if you build against a SNAPSHOT version. That's probably obvious, but seems worth explicitly calling out here, and perhaps explicitly documenting somewhere, if we do do this. Are you cool with that?

My time for this project is unfortunately more limited than I personally would ideally like it to be - but I'm happy to try to help e.g. at least with code reviewing proposed PRs from community members for this, if @icrc-fdeniger you would like to work on this?

[icrc-fdeniger]

We fully understand the "unstable" implication and if we use a SNAPSHOT we have to assume :)

I can help on this topic but I propably will need some help on the way artifacts publications are done: I can see that some aar resources are pushed to google repository. So my first question was: could we publish SNAPSHOT on google repo as weel ?

And I didn't see any publication task in the current repo. So maybe the publication is done via another CI/CD tool.

[vorburger]

I can help on this topic but I propably will need some help on the way artifacts publications are done: I can see that some aar resources are pushed to google repository. So my first question was: could we publish SNAPSHOT on google repo as weel ? And I didn't see any publication task in the current repo. So maybe the publication is done via another CI/CD tool.

My (personal) view, and recommendation how to go about implementing this, is... no. IMHO, an open source project's CI/CD should be completely "open", with all related configuration in the public Git repo of the project - if at all possible. I would therefore recommend that in order to implement this issue, we completely ignore any possibly existing Google internal CI/CD which may be used for publishing releases to a Google Maven repository, and "separately" add a GitHub Action YAML to this repo which simply continuously pushes each commit to this repo's default branch to maven.pkg.github.com.

@santosh-pingle I'm obviously very happy to be "contradicted" 😸 by you (or any other maintainers) about this, if you disagree!

[aditya-07]

@vorburger Looking at other google projects and some famous open source android libraries, Sonatype OSS seems to be used a lot for publishing snapshots.

Guava (google) : https://github.com/google/guava/blob/master/pom.xml#L282 Gson (google): https://github.com/google/gson/blob/main/pom.xml#L80 Moshi : https://github.com/square/moshi?tab=readme-ov-file#download Retroflt : https://github.com/square/retrofit/tree/trunk?tab=readme-ov-file#download Glide: https://bumptech.github.io/glide/dev/snapshots.html#about-snapshots

[vorburger]

@aditya-07 Sonatype OSS (=AKA "Maven Central") is a possible alternative to GitHub Packages, certainly.

However, my (personal) view, and recommendation how to go about implementing this, is still to use GitHub Packages.

The reason for this is simply to make this FR simpler to implement, and more "community owned". That's because, with:

• GitHub Packages: There is no need to deal with security hassles for Authentication, at all. GitHub just does this for us; right, and securely. (They know what they are doing.) Any community member can therefore contribute a PR to publish Maven artifacts to GitHub Packages. @icrc-fdeniger, please have at it!

• Sonatype OSS: Here, a Googler needs to make the credentials which allow a GitHub Action to deploy to the com.google.android.fhir "namespace" on Sonatype available, via a GitHub Secret. (And first apply at Sonatype to reserve this package; unless we've previously already done that for releases; I don't know.) And it will occasionally break, and have to be maintained by Googlers, only; community members cannot help. I have actually done this kind of stuff for other open source projects, and actually do this for some my personal projects for which I make releases, not SNAPSHOTS, available on Maven Central = Sonatype OSS (such as https://github.com/MariaDB4j/MariaDB4j and https://github.com/vorburger/ch.vorburger.exec and https://github.com/vorburger/ch.vorburger.fswatch. This is more involved. I wish I had the time to engage on enabling this. But I do not. And it's not a good use of the time; using GitHub Packages for this purpose (as above) is just so much simpler.

For end-users (developers), the results is similar - they just have to add https://maven.pkg.github.com/google/android-fhir/... to the Gradle configuration for Maven repos of their project. Whether Gradle pulls those JARs (or AARs, or whatever) from Sonatype or GitHub really doesn't matter, in the end.

[icrc-fdeniger]

• Just created a PR using GitHub Packages as suggested by @vorburger.
• Checked on my own fork with success.
• Just have a question related to version mngt but not a blocked for me :)