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:
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.
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.
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:
Do not remove SNAPSHOTs of referenceapplication distro. It cannot be done in nexus, which can only clean up the whole snapshots repo.
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…
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.
This is the recipe 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.
@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.
Basically, we’ll fix all that with the 2.5.1 release. Give us a week…