REST module release

Development
1

Hello all–

We’ve got a fix in the REST module we’d like to get into our distribution, and it looks like the module hasn’t been released in quite some time, so I’m going to go ahead and kick off the 2.17 release…

Mark

2

Okay, scratch that… we can’t “properly” release the REST module as it is because there’s a a 2.1 omod subproject that relies on OpenMRS 2.1, and I believe there isn’t a released versino of OpenMRS 2.1 yet. I see a few options:

  1. Just wait until OpenMRS 2.1.0 is released before we release a new version of the REST module (I can just depend on a SNAPSHOT version of REST in the PIH EMR, it’s not a huge deal)

  2. Go ahead and release the REST module as-is, forcing it to ignore the error caused by the snapshot dependency

  3. Do a release of REST without the 2.1 submodule entirely

Number 2 sounds like it might be the best solution?

Oh, and if someone wants to give me admin rights on both the JIRA project and the module repo, then if we do end up doing the release I can update the release in JIRA and upload the new version to modulus… :slight_smile:

@raff @darius

Take care, Mark

3

Does anybody know why rest depends on 2.1? I think that’s a mistake since it’s an unreleased version and we should correct it.

4

It doesn’t necessarily depend on it, there’s just a 2.1 omod that I assume provides some sort of custom support for 2.1… glancing quickly, looks like a change to the ConceptSource resource?

Take care, Mark

5

You can add a maven argument to the build command to tell maven which sub projects to build, this way you exclude the 2.1 sub project, it think it is a pl argument that you can use, or you can use profiles to exclude that sub project

6

I think this makes sense, as long as it’s just a compile-time dependency that we’re ignoring, and the generated omod loads fine in older versions of openmrs-core.

7

@mogoodrich, I gave you all needed permissions to do the release.

I don’t like the idea of releasing with a snapshot dependency as we may hit issues with modules depending on that release when the SNAPSHOT is gone…

I would comment out omod-2.1 in the main pom and omod-2.1 dependency in omod/pom.xml just for the release i.e. your 3rd option.

(most preferably we should use profiles and do not include omod-2.1 in the release profile as @wyclif suggested, but it requires extra time to play around with it)

8

It’s not a blocker for me now since we are relying on the snapshot in production, but I should be able to take the time to do number 3 as @raff suggests… seems like it would be good to get a release out with all the latest?

Take care, Mark

9

I just ran into this issue when I tried to release as 2.17.0.

I have another idea; what if we tag master as “2.1.0-prealpha” and deploy that to maven. Then we can switch the dependency in webservices.rest to point to that one.

@raff, what do you think about that, versus commenting things out in pom.xml?

10

@darius, it may not be a good idea. The “alpha”, “alpha-1”, etc. qualifiers are treated in a special way and positioned as older than 2.1.0-SNAPSHOT, but not sure what happens when you add “pre”. Maven may consider 2.1.0-prealpha newer than 2.1.0-SNAPSHOT, which would be bad… You would have to check what https://maven.apache.org/ref/3.3.3/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html returns.

11

Good point Rafal. I’ll just comment things out.

12

For future reference, here is how I temporarily commented out the snapshot dependency https://github.com/openmrs/openmrs-module-webservices.rest/commit/d8b50d0e4ea981065f3d28b5e5df8d9a5ea5bab3

And here is how I restored it: https://github.com/openmrs/openmrs-module-webservices.rest/commit/559466746dd858e13707fa0323623b03180d01d6