Who should have write access to deploy to our maven repository?

Community Infrastructure
21

So when deploying an artefact to JFrog, we can configure it to automatically copy artefacts matching a certain REGEX to be deployed to a bintray repository automatically. It used to work, currently not working, but I have hope their support will eventually sort that out.

At this moment, any artefact that is deployed to maven repository ‘modules’ that matches ‘(.)/(.)-omod-([^-]*).(jar|omod)’ would be automatically deployed to Bintray OpenMRS/omod

The options I see are:

  • PIH (and UgandaEMR) are also deployed to bintray OpenMRS/omod. It’s indistinguishable in bintray which modules are community based or for you, and we continue to control permissions to that.
  • We create new bintray repositories in the OpenMRS bintray account/organisation, like ‘omods-pih’ and ‘omods-ugandaemr’. It’s easy to distinguish between modules that community based or not, but permissions and control access still done by us.
  • Each one of you create your own Bintray accounts/repositories. It’s free and you don’t have to host anything, and we configure JFrog to deploy there.
  • Neither of you require bintray at all.

Hard for me to tell which one fits your requirements and our community.

22

So I was able to configure a couple of our PIH modules to deploy to the the new repos @cintiadr created and everything seems to be working. I’ve created a task in PIH Jira to go through and rework all of our module deployments as needed. As part of this task, we are planning on taking a hard look at the existing modules in PIH Github to see if any are general purpose enough that they could/should be moved to OpenMRS Github, and therefore OpenMRS CI. So our plan would be for each module to either:

  1. Move this module to OpenMRS github, and create a build plan in OpenMRS CI to do the build deploy, or
  2. Make the change listed to the pom.xml for the module so that the job now deploys to the PIH-specific repos

Generally, I think we should have as much as possible in the main OpenMRS repos so that others in the community are aware of their existence.

If we do this, it’s quite possible that we don’t need a PIH Bintray at all… and if we do, I’d be fine with setting up a PIH account, assuming it’s simple. I quickly took a look at getting an artifactory account for PIH and that seems a little more complicated.

Take care, Mark

1 Like
23

@cintiadr I hope you are keeping well, just checking if you completed making the changes for UgandaEMR modules as we are currently unable to release as before

Thanks in advance

24

As I mentioned via PM, I’m not being to come here more than once or twice a week. No changes were done to jfrog regarding to that, as far as I’m aware.

25

@ssmusoke if you are recently having trouble publishing to the Maven repository where you were not having trouble previously, there is an issue around the specific url that some of us have been having trouble with. Try adjusting the distributionManagement section of the poms for the modules that you are trying to publish. For example, I see this in your aijar module:

	<distributionManagement>
	<repository>
		<id>openmrs-repo-modules</id>
		<name>OpenMRS Modules</name>
		<url>https://mavenrepo.openmrs.org/nexus/content/repositories/modules</url>
	</repository>
	<snapshotRepository>
		<id>openmrs-repo-snapshots</id>
		<name>OpenMRS Snapshots</name>
		<url>https://openmrs.jfrog.io/openmrs/snapshots</url>
	</snapshotRepository>
</distributionManagement>

You’ll want to try changing the one that refers to mavenrepo.openmrs.org to refer to openmrs.frog.io like this:

	<distributionManagement>
	<repository>
		<id>openmrs-repo-modules</id>
		<name>OpenMRS Modules</name>
		<url>https://openmrs.jfrog.io/artifactory/modules/</url>
	</repository>
	<snapshotRepository>
		<id>openmrs-repo-snapshots</id>
		<name>OpenMRS Snapshots</name>
		<url>https://openmrs.jfrog.io/openmrs/snapshots</url>
	</snapshotRepository>
</distributionManagement>

Give that a try and let us know how it goes…

Best, Mike

26

Thanks @mseaton let us try this out

27

Thanks @mseaton this is just what the doctor ordered, now the releases are working perfectly, infact may explain lots of failed snapshot updates over the last couple of weeks

28

I mentioned via PM, but here for others to see: maven newer than 3.3.9 is having that problem with our maven repository. Still to be decided what’s going to be about it, I raised a ticket with maven itself. (yeah, fun and games!)