Multiple Maven Repositories hosting org.openmrs.module artifacts?

[mseaton (Mike Seaton)]

@cintiadr

From the maven (tool) perspective, to keep consistency, we need to make sure is that a certain groupId/artefactId/version doesn’t exist in more than one repository. An easy way is to ensure we don’t have duplicated artifactIds; another way is to ensure people have different groupIds.

I’m ok with either approach. We’ve been so far recommending the former, but changing to the latter is not a bad idea.

I fear that ship has already sailed. It is likely possible to start encouraging more unique group ids, but so much of the community is used to using the org.openmrs.module package that change will take a lot of time. I wouldn’t even be surprised if there were assumptions baked into code around this here or there, though I really hope not.

Regardless, if JFrog provides an instruction to those who are applying to be able to use Artifactory for their code that their groups must be unique to them, there might actually be some checking done around it, and I didn’t want to make assumptions that it was just our own usage we had to monitor. So this led me to hold off knowing that there are org.openmrs.module artifacts in other Maven repos.

Also, in this particular case, the rwandaemr module already has artifacts in the OpenMRS Artifactory instance. So we’d have to have a very careful transition plan to ensure we upgraded code to a new version before starting to use a new Artifactory instance moving forward, and then even after doing so the same module would have artifacts in 2 different Maven repositories. Seems like it could get ugly. Is there a process where one could move from one Maven Repo to another?

@cintiadr

My problem is a far of scaling (and securing) this.

Right, which is why I was trying to use a different Artifactory instance. But that’s where the issue above occurred, so what’s the right way to proceed?

@mseaton

Do you or does anyone here have experience using Github Packages? If we can move to consolidate around github permissions for specific repositories for both code authoring and code release/deployment, rather than separate access privileges needed for a centrally managed server, that would seem like an improvement, though there may be drawbacks to consider.

I wanted to explore this option as well, so I spent a bunch of time trying this out, and it was super easy to get set up and I was really excited about it at first, but then I hit 2 major limitations:

1. Every codebase ends up published to it’s own Maven repository. There isn’t one central Maven repository they all end up in. That means if you have 4 modules, and depend on each in your distribution POM, you’ll need to have 4 different <repository>...</repository> entries in your POM (one for each module).

2. The above could be manageable if read access was anonymous. But despite the fact that the repository is public, code is public, etc. you can only install a package from Maven if you first authenticate using your github token to demonstrate that you have read access on the repository. So you need to have a private servers.xml file in your .m2 directory that contains entries for each of these 4 repositories, all with your github credentials in them. Ugh.

Until those issues are resolved (and in threads I have seen, github representatives seem to acknowledge this as a major limitation and problem), I won’t be looking at Github Packages as a Maven Repo.

For now, I’m sticking with the OpenMRS Artifactory, but it would be great to find a proven alternative that can play nicely in our ecosystem.

Best, Mike