Reference Application distro 2.6 released to maven?

Someone must have accidentally released Reference Application 2.6… It needs to be taken down from our maven repo ASAP.

It is a bad practice to remove released artifacts from nexus as they may have already been cached by devs locally. The released artifacts cache does not expire so devs need to remove these directories if present:

user_dir.m2\repository\org\openmrs\distro\referenceapplication-package\2.6 user_dir.m2\repository\org\openmrs\distro\referenceapplication\2.6 user_dir.m2\repository\org\openmrs\distro\referenceapplication\2.7-SNAPSHOT


There is also 2.7-SNAPSHOT, so I guess it should be deleted too.

1 Like

Yes, I did that too.

I presume this was where it was accidentally released.

@darius @raff Now that we are on this thread @dkayiwa and I have just found a bug in the Reference Application 2.5 pom - which breaks all travis builds due to the 2.5-SNAPSHOT not being found with this error

So my question is how does this get fixed after the release - I personally would not want to jump onto the 2.6-SNAPSHOT train since 2.5 provides a stable fixed version to base on.

I could delete and recreate the tag with the fix, if there are no objections.

Even if you recreate the tag, it won’t change the POM in nexus. Even if you change the POM, maven won’t change any downloaded 2.5 downloaded to build agents and to developers’ machines.

It might be just easier to release 2.5.1. Maybe delete 2.6 from tag and nexus and not reuse it might be the safest.

@dkayiwa A 2.5.1 sounds adequate at this point and it makes sense

@ssmusoke, this is a prevailing issue with the way we structured the builds, see Maintaining SNAPSHOT Maven dependencies and Ref App build fails because distro version 2.4-SNAPSHOT no longer present

Basically, you can’t release the referenceapplication module, because you need to release the referenceapplication distro first. You can’t release the distro, because it needs the referenceapplication module to be released. It applies to all modules, which import versions from the referenceapplication distro.

Let’s finally do something about it… In the past we considered 3 options:

  1. Do not remove SNAPSHOTs of referenceapplication distro. It cannot be done in nexus, which can only clean up the whole snapshots repo.

  2. Move versions out of the distro project to a separate pom project, which can be released before the distro is released. All modules included in the distro can depend on a released version of that pom project. The release process gets cumbersome as you need to decide up front on versions of modules to be included in the final distro release and set them in the pom project (even before releasing modules). Way to complex…

  3. Stop using the distro pom in modules and declare versions in modules explicitly. It’s more work to maintain versions in such a case, but it’s cleaner. We still want to build modules in our CI against the latest snapshots of dependent modules, but we can use a dedicated maven plugin for that.

Given 1st isn’t feasible and 2nd seems overly complex, we should go with 3rd.

I’ll work on fixing one of the refapp modules and come up with a separate profile for CI, which can be used in all other modules. Next we can apply changes to all modules and do the 2.5.1 release, which fixes things. I expect us to be done in a week and do the 2.5.1 release.


Should I remove anything from nexus?

@cintiadr, I did delete 2.6 from nexus. No need to delete anything else.

So what are the next steps to fix this issue which is breaking travis builds?

This is the recipe :slight_smile: Basically, we’ll fix all that with the 2.5.1 release. Give us a week…

Meanwhile I redeployed 2.5-SNAPSHOT to the nexus repo and disabled deleting SNAPSHOTs after releases. It’s a temporary fix to unblock you, but we’ll not support that once we release 2.5.1 with the fix. Your builds should be working again.

@raff Awesome tests pass already … I am happy to upgrade to 2.5.1

@raff, a few months ago Mark and I had decided that we should start making this change. (Discussed here and in following posts.)

So, +2 to going ahead and making this change. Thanks for taking it on!

@darius when you say “this change” are you referring to just “stop using the distro pom and declare versions in modules explicitly” or are you also talking about adding automatic version upgrades to the build pipeline (assumedly using the maven versions plugin)?

In the thread you link to, you suggested that we might not want to automatically update, and so I dropped working on it at that point (I also had ran into some difficulties with it that I highlight on the thread) and it looks like we never picked up the discussion.

Personally, I think we are going to want automatic updates, at least for some modules.

Take care, Mark

I meant that we should definitely “stop using the distro pom and declare versions in modules explicitly”.

I am unconvinced about “adding automatic version upgrades to the build pipeline” (but not necessarily opposed).