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.