Today I was upgrading Ehcache’s JGroups
replication module to apply a patch. I needed to upgrade JGroups. Fine. I went into IntelliJ and updated my Maven repository indexes as they were a little stale, then clicked on the version number and used auto-complete to find the new versions. I found 2.7. That did not compile with the patch. I went back to the submitter. He then informed me that JBoss had changed
After hunting around I had to change it to:
It would have been nice if the old name could have been mapped to the new location.
I thought I was done. But no, in the meantime JGroups decided to become more correct and go to a package name. Now, Ehcache did this about three years ago. So the old and new are as follows:
This whole thing was a hassle. Played out over the entire development community it turns into a lot of wasted productivity. To me each of these changes is no different to people changing interfaces in code. You have to change to rebuild. As it happens, later on I found out JGroups also did that with getLocalAddress, which is no longer castable to IPAddress.
This is a pet hate of mine. Why create work for your users? I always strenuously try to avoid these changes.
As to Maven I have been observing a trend where much of what you need is no longer in the central repository. It is now mainly a federated system. The central repo is therefore kind of dead.
This is now getting to be not much better than the old days of having to go hunting for software on a multitude of websites. But now it is even worse than that. You also have to then search on those web sites for their Maven repository, which is often buried somewhere, and then their maven coordinates for the artifact you want. I think this is turning into a software anti-distribution system. And then back to the beginning of this post – having done all that you can expect to do the same each time you want to upgrade, because of a lack of regard for backward compatibility.