#2503 push SNAPSHOT Maven artifacts to github Packages

[icrc-fdeniger]

Fixes #2503

Description
Publish Maven artifacts in GitHub Packages

Type
Feature

Checklist

• Tests done https://github.com/icrc-fdeniger/android-fhir
• Maven packages are deployed here: https://github.com/icrc-fdeniger?tab=packages&repo_name=android-fhir ( will be done on google/android-fhir)
• maven-repository.zip artifact is deployed as usual ( not sure about the usage of this artifact but not changes).
• See https://github.com/icrc-fdeniger/android-fhir/actions/runs/8798380904/job/24145256498 for a full deployment

Versions

• When the maven artifacts are deployed in GitHub Packages the SNAPSHOT prefix is used to follow Maven coventions.
• When the maven artifacts are deployed in official maven repositories, the SNAPSHOT prefix is not used ( as it's done actually as far as I can understand)
• In the PR, the artifact versions has been updated to next expected release version:
  • for instance, commonmodule will be automatically deployed with the version 0.1.0-alpha06-SNAPSHOT in GitHub Packages and with 0.1.0-alpha06 in the next release.

Suggestion/question
why not removeing beta/alpha as versions like 0.X.Y are considered as development version ?

Current Version	Used in this PR	Proposition
common:0.1.0-alpha05	common:0.1.0-alpha06	common:0.1.1
engine:1.0.0	engine:1.0.1	engine:1.0.1
data-capture:1.1.0	data-capture:1.1.1	data-capture:1.1.1
workflow:0.1.0-alpha04	workflow:0.1.0-alpha05	workflow:0.1.1
ontrib-barcode:0.1.0-beta3	ontrib-barcode:0.1.0-beta4	ontrib-barcode:0.1.1
contrib-locationwidget:0.1.0-alpha01	contrib-locationwidget:0.1.0-alpha02	contrib-locationwidget:0.1.1
knowledge:0.1.0-alpha03	knowledge:0.1.0-alpha04	knowledge:0.1.1

if a dev Team wants to use an alpha/beta version it can use a dependency to a SNAPSHOT version ( the "unstable version created from the last build").
it's also possible to specify the artifact of a build with by example: engine-1.0.1-20240423.083712-3

[vorburger]

LGTM, based on an initial quick glance... but a "core team" member and not just me should probably also rewiew this PR.

[icrc-fdeniger]

Hello @santosh-pingle, @ktarasenko
please tell me if this PR need to be modified. I understand that the version updates are the "tricky" part and will be happy to modify this. My point was to update them to the next version as GitHub Actions should produce SNAPSHOT of next versions.

Thanks

[vorburger]

@icrc-fdeniger FYI the artifact version number changes introduced here will cause build failures once you rebase this after #2533 is merged. The required fix (after you have rebased it, not right now) is as simple as changing those version numbers also in the (new, TBD) docs/use/api.md file; hopefully that's trivial. Please do shout if unclear!

@MJ1998 @santosh-pingle @ktarasenko merge this only after #2533.

[icrc-fdeniger]

@vorburger @santosh-pingle @ktarasenko should be ok now

[vorburger]

@vorburger @santosh-pingle @ktarasenko should be ok now

LGTM! I say let's merge this... @santosh-pingle @ktarasenko @MJ1998 no objects, right?

[MJ1998]

LGTM but requesting @aditya-07 to approve.

[MJ1998]

Thanks for this PR @icrc-fdeniger. LGTM.

About the version proposal we would wanna keep the alpha/beta naming conventions. Reason - Using alpha and beta suffixes aligns with established conventions in semantic versioning and open-source software development. So we would like to stick with it.

[MJ1998]

LGTM

[icrc-fdeniger]

@santosh-pingle any news on that PR ?

[jingtang10]

actually one last thing before merging - i feel we're really publishing a snapshot of the HEAD, instead of any particular versions... I couldn't find a way to do this but when we're publishing github packages can we just use the build id or something that is not tied to our version number for public releases?

@icrc-fdeniger @vorburger

[MJ1998]

actually one last thing before merging - i feel we're really publishing a snapshot of the HEAD, instead of any particular versions... I couldn't find a way to do this but when we're publishing github packages can we just use the build id or something that is not tied to our version number for public releases?

@icrc-fdeniger @vorburger

I guess this is better because someone might be using a particular snapshot in their dependency and could upgrade it to the latest build snapshot which is available. On the other hand, using version will overwrite the snapshot and the the developer may get confused that even though they are using the latest snapshot available they are not getting all the features added.
Only problem I see is that each PR will push a snapshot and this can grow huge... So we might need another GitHub action (if possible) to delete old snapshots?

[icrc-fdeniger]

@jingtang10 @vorburger documentation added.

[bashir2]

OK, now onto github packages - with this change, do we always overwrite the SNAPSHOT? so if I have a PR in development, and I push a new commit it will overwrite the github packages?
Another thing we might need to be careful about is just any incurred cost - github.com/features/packages#pricing. With our repo under google organisation I'm hoping that we'll be covered by the google organisation quota/allowance. But I will investigate.

@jingtang10: another solution could be to use jfrog.io or https://oss.sonatype.org as a maven repository as it's free for opensource project and it will be easier for other projects to integrate android-fhir as a SNAPSHOT dependency : we don't need to provide a Git Token to download artifacts ( see https://github.com/icrc/openmrs-android-fhir/blob/main/README.md#setup).

@bashir2 do you push any project to maven central? i can't remember.

Sorry forgot to reply this earlier; yes we do: https://central.sonatype.com/search?q=com.google.fhir.gateway

@icrc-fdeniger I have not read all the discussions on this PR but IIUC you want to use SNAPSHOT versions of the android-fhir libraries in your dependent code. One approach that I have seen people use is to check-out/build locally if SNAPSHOT version of a dependency is needed. IIRC, OpenMRS is also set up that way. So for example, if I needed to change something in openmrs-core and then use that in development of one of OpenMRS modules, I would checkout core and do a mvn install locally (can be built as part of CI process too). Would that solve this problem?

[icrc-fdeniger]

OK, now onto github packages - with this change, do we always overwrite the SNAPSHOT? so if I have a PR in development, and I push a new commit it will overwrite the github packages?
Another thing we might need to be careful about is just any incurred cost - github.com/features/packages#pricing. With our repo under google organisation I'm hoping that we'll be covered by the google organisation quota/allowance. But I will investigate.

@jingtang10: another solution could be to use jfrog.io or oss.sonatype.org as a maven repository as it's free for opensource project and it will be easier for other projects to integrate android-fhir as a SNAPSHOT dependency : we don't need to provide a Git Token to download artifacts ( see icrc/openmrs-android-fhir@main/README.md#setup).

@bashir2 do you push any project to maven central? i can't remember.

Sorry forgot to reply this earlier; yes we do: central.sonatype.com/search?q=com.google.fhir.gateway

@icrc-fdeniger I have not read all the discussions on this PR but IIUC you want to use SNAPSHOT versions of the android-fhir libraries in your dependent code. One approach that I have seen people use is to check-out/build locally if SNAPSHOT version of a dependency is needed. IIRC, OpenMRS is also set up that way. So for example, if I needed to change something in openmrs-core and then use that in development of one of OpenMRS modules, I would checkout core and do a mvn install locally (can be built as part of CI process too). Would that solve this problem?

Thanks @bashir2 for your answer.
You are right: we want to use SNAPSHOT versions of android-fhir in our dependent code.

For OpenMRS ( given as an example but true for all projects :)) there are 2 main use cases:

1. the situation you describe: you want to modify openmrs-core and so you have to check-out/build locally. This use case is clear.
2. you want to test your application with the latest version of openmrs-core. In this case, the usual way is to use SNAPSHOT version to avoid redoing the full check-out/build process.

For the second point, for sure developpers can check-out/build the source locally but:

• It's a long process: I must be sure that all developpers in our team performed a pull/build locally of android-fhir. Maybe some of them will forget or a commit in android-fhir can break some of our features ( and we will have to checkout an earlier commit) , etc...We will have to deal with all these situations.
• With a SNAPSHOT dependency, the update will be automatically done and we can force it with the option --refresh-dependencies to be sure we have the latest. If a commit in android-fhir breaks our application, we can modify our dependencies to use a pinned snapshot version temporarely ( until the commit is fixed in android-fhir or our application is modified) and so all developpers can go on.
• Impossible or very complex to integrate this approach "check-out/build" in a CI Tool to launch integration tests or to generate demo "apk". This point is surely questionable but no choice for now if we want to use the latest improvements in FHIR engine concerning OpenMRS. As soon as a FHIR engine version is released and contains all features we need we will use this released version and then we will stop using SNAPHSOT for sometimes to release our application. And then we will prepare a v2 and use SNAPSHOT versions again to be sure we are up-to-date with latest dev ...

IMHO, deploying SNAPSHOT versions in Maven Central will be better than using GitHub packages ( no token needed and no extra cost). For now this PR is using GitHub Packages but will be happy the modify it to use Maven Central.

[vorburger]

to use Maven Central

Maven Central is... erm, "evolving" ("cough"), and I think they won't support SNAPSHOT repos in the future.

Just FYI, vorburger/ch.vorburger.exec#212 (unrelated, just FYI).

[jingtang10]

to use Maven Central

Maven Central is... erm, "evolving" ("cough"), and I think they won't support SNAPSHOT repos in the future.

Just FYI, vorburger/ch.vorburger.exec#212 (unrelated, just FYI).

hi @vorburger - can you pls add more details on maven central's support for snapshot?

[vorburger]

hi @vorburger - can you pls add more details on maven central's support for snapshot?

My advice is to stay clear of Maven Central, for SNAPSHOT.

I advise to either use GitHub packages (with some auto clean), or simply a SNAPSHOT repo on the docs site.

[jingtang10]

tweaked a few things in the doc.

thanks so much @icrc-fdeniger for this! excited for this change!

[icrc-fdeniger]

tweaked a few things in the doc.

thanks so much @icrc-fdeniger for this! excited for this change!

thanks this change will help us :)
Do I have something to do or just wait for the workflow to go on ?

[jingtang10]

tweaked a few things in the doc.

thanks so much @icrc-fdeniger for this! excited for this change!

thanks this change will help us :)
Do I have something to do or just wait for the workflow to go on ?

No I've enabled auto merge so hopefully it'll go in once tests pass