Hey Elliotte, If the project you are referring to is the one that I'm thinking about, the project I'm working on was in the same situation a couple of years back.
In the last 4 years, we've spent a significant amount of time and resources to migrate Trino (https://github.com/trinodb/trino) from Travis/Jenkins to Github Actions, from javax.* to jakarta.*, from JDK 8 to 11, then to 17, 21 and recently to 22. We've upgraded our Maven infrastructure, reported bugs that we've encountered, contributed some fixes back and got to the point where we can easily move to the latest Java version when it's released. We are now ready for Maven 4.0 as we are continuously forward testing alpha versions and reporting problems back to get next alphas even better and closer to GA. That said, all of that didn't happen overnight and to be honest I was frustrated countless times trying to replace and upgrade some legacy stuff, before we got to the point where we are today. With every problem that we've encountered, we have received a tremendous amount of help from different OSS projects and communities which always encourage us to move forward, test new things and contribute fixes/improvements/feedback. It's hard for me to believe and accept that these big companies, having these vast resources, can't afford the same work that we did. And since it's not a matter of resources, I know that this is a matter of recognition by project leaders that staying on old, legacy build infrastructure/tools, dependencies has increasing cost and brings only risks with little to no benefits at the same time. If you accept these risks willingly, you can't expect that others will share that pain with you. Staying legacy isn't a way forward for any project and for the IT industry in general. I acknowledge the pain that you have described and feeling "that can't be done" but at the same time I know that it isn't impossible, just hard/time-consuming/tedious/frustrating and requires both a strategic decision, investment and meticulous work, nothing less, nothing more. On Sat, Apr 13, 2024 at 4:38 PM Matthias Bünger <runningj...@web.de.invalid> wrote: > Hey all, > > when I gave my talk about Maven 4 some days ago at the Javaland > conference I started with a quick "what Maven version do you use" > question and there were also several hands who use 3.6 and 3.3 (!). I > hope I could convince them to upgrade - so it's the same with Java > versions: There are always people who use very old out of support version. > > But as you wrote yourself: It's seems more than a "frozen" CI setup than > a Maven problem. > > Matthias > > Am 13.04.2024 um 13:21 schrieb Elliotte Rusty Harold: > > Maybe it should be, but I wanted to drop a note that about a month > > after December's decision to require Maven 3.6.3, I shifted onto an > > open source project that's been around for 10+ years, is actively > > backed by two large tech companies, and still depends on Maven 3.5.x > > in the continuous integration build. Bleah. > > > > I've been trying to upgrade it, but so far without success. 3.5 seems > > baked pretty deeply into the Docker images or some other part of the > > CI infrastructure that isn't easy to change. This project could well > > be using Maven 3.5 for years to come. It's even possible we will > > rewrite the whole codebase in C++ before we manage to get past Maven > > 3.5. (I wish that was hyperbole. It's not.) > > > > I think we tend to overestimate how fast the installed base updates, > > whether it's JDKs (I got a bug report from someone still using Java 7 > > yesterday), Maven versions, operating systems, or pretty much anything > > else. None of us see more than a small fraction of the projects out > > there. It is very easy to look at that small fraction and draw > > conclusions that are falsified with a larger or different sample. > > > > I didn't know about this dependence on Maven 3.5 until I changed > > projects in January. I haven't seen 3.3 lately, but I wouldn't be > > surprised if it's still in use in multiple organizations, perhaps > > because it's what's installed by default in some old Linux distro that > > should also be retired but isn't. Absence of evidence is not evidence > > of absence, including when considering which Maven versions developers > > actively use. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
