Releasing modules with snapshot dependencies

Looks like version 1.11 of emrapi module was released when it has snapshot dependencies, i think this is not exactly desired. E.g it depends on 1.2-SNAPSHOT of metadata sharing which is not yet released and the code it was build against can change meaning you can get errors because of class incompatibilities at runtime. We also need to remove this configuration from modules that are released from bamboo so that the release fails if there any snapshot dependencies. Apparently, this wiki guide for setting up a module to be released from bamboo is the one that suggests this but i think it is wrong.

1 Like

I agree that we shouldn’t be releasing with snapshot dependencies. I forget if there was a particular reason we were allowing this?

Mark

I think the reason why we allow snapshot dependencies is because some modules add the distro as a dependency to pull in other dependencies and the distro is always at a snapshot version since it is the last to get released, so you wouldn’t be able to release these modules before the distro is released which kind of poses the ‘chicken or egg first’ dilemma

Modules depend on the thing that depends on them? Why are we making cyclic dependencies?

It is indeed a technical limitation of the way we have tied things together. I.e. to declare refapp module versions in one single place, i.e. the distro pom, modules need to depend on a snapshot version of the distro, as their parent pom. This is unfortunate, but it should only be a build-time dependency, and if we do things right, the generated module artifacts won’t have any runtime snapshot dependencies.

We should not be publicly releasing module versions that have snapshot dependencies on other modules. I believe that the Bahmni team has done a few releases of the emrapi module, and it’s possible that they haven’t been following the full release process (e.g. I think they’ve been doing the JIRA bookkeeping but not uploading the released versions to the module repo). @shruthidipali can you comment on this?

@wyclif, did you verify for sure that some released version have actual snapshot dependencies on other modules? Or could it just be a snapshot dependency on the parent pom?

@shruthidipali, were you all aware that there are (or may be) snapshot dependencies on other modules in the emrapi releases you’ve been doing? Is that intentional (e.g. you are okay doing these as “internal releases” or something) or is it unwelcome?

The distro-referenceapp pom has references on snapshot versions of modules defined… for instance, 1.2-SNAPSHOT of metadata sharing (at least until Rafal changed it earlier today). Looking at the history, that hasn’t changed in a couple months. Since emr-api module depends on metadatasharing, and uses the distro-referenceapp pom, assumedly every version of emr-api released during that time would depend on 1.2-SNAPSHOT metadata sharing?

Seems like we’ve been trying to release the modules “in order” based on dependencies, but there’s nothing enforcing that we maintain that order?

There must be a better way?

I bet that we could find (or write) a maven plugin that will fail the build if there are any actual snapshot dependencies (and you’re in the release profile).

(Maybe the enforcer plugin can do this?)

@mogoodrich just mentioned what i was about to say, i realized this with emrapi and MDS, emrapi has been depending on MDS 1.2-SNAPSHOT for a while and i see that emrapi 1.11 was released very early today (Thursday) EST, i believe this happened before Rafa downgraded the MDS version around midday today, emrapi 1.10 was released 15+ days ago and i believe that too was released off a snapshot version of MDS.

Looks like there is some modules setup up with their dependencies to be fetched from the distro but whoever set them up overlooked something mentioned on the ‘configure module to be released from bamboo’ wiki page i.e keep the module dependency version properties in the root pom because they get used in the config.xml file. You can see that the emrapi 1.11 tag here has the maven property names instead of actual versions in the config.xml, am not sure if this module and it dependents will fail to start or will always start. And of course looks like emrapi releases haven’t been uploaded to modulus since 1.6

I think it was an oversight to not upload the released versions in the module repo. However, I just tried to upload http://mavenrepo.openmrs.org/nexus/service/local/repositories/modules/content/org/openmrs/module/emrapi-api-1.11/1.11.1/emrapi-api-1.11-1.11.1.jar but I get a NPE. Can someone try this as well?

We were not really aware of emrapi’s snapshot dependencies. Adding that as a step in our wiki. Thanks @wyclif for fixing this.

-Shruth

1.11.1 is already released, you don’t have to upload anything

Catching up on my email just now.

It’s possible to always do a new enforcer rule, it shouldn’t be hard.

Maybe this one https://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html with failWhenParentIsSnapshot = false could be enough?

About releasing with snapshots, I’m not going to say it’s a good idea.

But locking it is a tradeoff. You’d have to only release modules in a specific order, and change the parent pom to reflect a non-snapshot dependency.

If that’s something you are willing to have (something that was probably not the case a year ago), I’m all for it. At the end of the day, I’m not the one feeling the pain of the releases.