So, JFrog apparently has decided to sunset Bintray on May 1st [blog post]. While this doesn’t affect Artifactory (our Maven repository), we do use Bintray to store OMODs and as the backend for most (all?) of our packages on addons.openmrs.org. There was some discussion last year over the value of Bintray and it seems like JFrog have also decided that there isn’t a great deal of value-added by Bintray either.
Thanks for the updates @ibacher unfortunately i didnt knew that bintray is a Product from Jfrog 
Can we move toward using GitHub release page for artifacts and point our AddOn links to those? Are there limits or downsides of releasing omods, for example, within the “Releases” of their official GitHub repo?
I could never really figure out the intersection / overlap between Bintray and Artifactory. Our maven repository is the source of truth for our release artifacts for all practical purposes. Can we link into that?
Probably? I think the hardest thing to deal with is going to be OWAs since those seem to be published to and downloaded from Bintray exclusively.
I the only thing we might lose is download counts. I can’t see an obvious way to get those from the GitHub API; Artifactory at least seems to store a download count, but it’s structured differently from the thing we’re using in Bintray (Bintray at least gives the appearance of providing a download count per-artefact regardless of version; in Artifactory, they seem to be linked to a specific version).
Since we are running away from OWAs, i would not see this as a blocker. 
Also, this leads to some annoying workarounds in deployment. Currently most artifacts can be pulled down from maven during the build process. But OWAs require a different mechanism (specify via url to download from), which doesn’t support the same underlying mechanisms or allow for the same type of releasing and versioning. Deploying OWAs to Maven as zip files with proper group/module/version/classifier, etc. would make including them in distributions a lot easier.
Mike
2 Likes
We could track clicks on download links within addons.openmrs.org and I believe the github API may expose download counts.
There’s also github packages. Though, we might run into issues with storage limitations/quotas. Losing older artifacts would be a bummer.
So I’ve dug a bit into the Addons code. Supporting Maven as a backend looks to be reasonably trivial, since I think the code basically already exists. There is a Maven backend, but it’s tied to the Nexus API. Judging by the comments the Maven backend was written as a stop-gap to migrate away from Modulus and then the more detailed Bintray backend added later.
While I’m on the subject, is there a particular reason we don’t publish releases to Maven Central? (Even the SDK hasn’t actually been updated there since 2018)
@ibacher / @burke / @dkayiwa - I wanted to raise this back to the top of our inboxes. Is there a plan underway to address the fact that Bintray is going away in a few weeks? If this is already handled, great, but if not can we get some time scheduled to review this?
I added support for Artifactory as a backend To the Addons project. Plan is to put that into production by Friday and then switch over to using the Artifactory backend.
Awesome - well done @ibacher ! Have we identified / covered any other uses of Bintray? The use caes I’ve encountered recently that I’m thinking is that the SDK has a lot of code and features around Bintray (pulling artifacts, publishing artifacts, looking up available artifacts and versions, etc). And all of our OWA releases are in Bintray with most tooling configured to pull OWAs down from there as needed.
Is there a plan to move all of the OWAs out of Bintray and put them in the new owa repository in Maven / Artifactory?
This is going to take some manual work, but I’ve at least saved all of the OWAs stored in the OpenMRS Bintray and plan to upload them to the Maven repo. I saw you added a PR for the SDK, which was the other component I was really concerned about.
@burke / @dkayiwa / @cintiadr Assuming we’ve sorted out addons.openmrs.org, the SDK, and move the OWAs to the Maven repo, is there any other community tooling that relies on Bintray?
@mksrom / @wyclif I notice the camel-openmrs component of openmrs-eip uses JCenter as a repository… Since that’s also going away, is there anything there that we explicitly require?
@ibacher from what I can tell - all of the released SDK artifacts only seem to exist in the openmrs-bintray repository (as this is what had been configured in the pom). I’ve just today changed the pom to point to the “snapshots” and “releases” repositories which will be used in the future (assuming no disagreements). Can we also move all of the artifacts that are in the openmrs-bintray repo over to releases?
I think that’s right. There’s a note at the end of the README that says:
The tag will be then built and deployed to Bintray. You will have to sign-in and sync with Maven Central.
My understanding is everything else on Bintray is somehow synced from Artifactory, but that’s all I know (I don’t actually have any access to OMRS’s Bintray). @cintiadr or @burke?
That’s correct. the Omods are deployed to artifactory as part of maven release, and then there’s a configuration we have in artifactory that, when triggered, will upload it to bintray.
Update on this: I’ve downloaded all of the artifacts I could from Bintray. This yielded 2159 distinct OMODs representing ~250 distinct OMRS modules. Of these, 154 OMODs available on Bintray had at least one version on Bintray that was not in Artifactory. Most of these represent quite old versions of modules, e.g. htmlformentry versions 1.0–1.8.1. A couple of them might represent modules that are not built on OMRS’s infrastructure (muzimacore, for example). Overall, we’re missing 870 artifacts that exist on Bintray, but not on Artifactory, so the priority will be to get those 870 OMODs uploaded to Artifactory.
Separately, there are 59 distinct OWAs representing 10 different OWAs. None of these versions exist in Artifactory for obvious reasons. I’ll also be trying to get those uploaded to Artifactory.
The process for uploading the OMODs is a little more straight-forward than the process for uploading OWAs, since the OMODs are largely generated from Maven builds and so determining the group, artifact id and version is quite easy. OWAs don’t have particularly standarised metadata, so will take more work to get uploaded.
Thanks very much for continuing to work on this @ibacher . Let me know how I can help with any of this. I think once we confirm that everything that was previously on Bintray is now available in Artifactory, we will likely want to create some tickets to do some cleanup of the SDK codebase to remove the Bintray-related features (and adjust them to point to Artifactory as appropriate).
2 Likes
Update on this: Turns out uploading OMODs wasn’t as straight-forward as I thought it would be. Several of them actually package the POMs that generate them and that somewhat interferes with the ability to just upload the OMOD. I’ll note that most of the OMODs that don’t have a corresponding version already in the Maven Repo are actually quite old.
I’ve uploaded all of the OWAs with the exception of ideliver (@paulamendola are there any objections to storing these in the OMRS Maven repo?).
addons.openmrs.org has been updated to index against Artifactory instead of Bintray. As part of this, we’re going to lose download counts, although that doesn’t seem to have been very interesting information anyway (Artifactory does store download counts, but supporting this will require more work on the AddOns server). This indexing should be finished in the next half hour or so.
I’m a bit worried about what will happen tomorrow, but hopefully we’ve caught most of what needed to be migrated.
PS Thanks @mseaton for your work on the SDK!