Eliotte, While I sometimes find your hunting and fishing stories amusing, I also find them very tiresome.
Maven is not a subcontractor or anything like that for any of the companies you keep talking about. Maven is not (contractually or in any other way) obliged to "deliver best experience" or even "support" to those companies you keep talking about. As it was said multiple times here, they are most probably happily using Maven3 and will keep using it. Please stop parroting these things _in relation_ to Maven 4. This is getting VERY demotivating, at least to me. I am here to have fun, and not to present some "corporate HOWTOs" I had experienced in my life (and very much hated). I understand your professional past had this and that taught you, but this is not your job. You are not better or worse by fixing or not fixing bugs here (or introducing them by doing other changes). This is an open source project, that does not account for spent hours, milestones and what not. Here the "do not touch until broken" is not in effect, as we do not aim for profit. There is no profit involved here. There is nothing "corporate" around here, this is supposed to be FUN. (in fact, there is: profit is when you have chance to sit with any of other maven-ers and have a beer with them, spend good time as you would with your friends, and NOT company coworkers. But this stands even for "online" chats, playing CSGO etc) So, I kindly ask you: Please stop. On Sun, May 25, 2025 at 1:30 PM Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > > On Sat, May 24, 2025 at 6:22 PM Martin Desruisseaux > <martin.desruisse...@geomatys.com> wrote: > > > Java 9+ for supporting JPMS. This is needed not only in some plugins > > (compiler, javadoc, maybe surefire), but also in some places of Maven > > core (class-path versus module-path, cache of module-info). Even if not > > everyone is interested in JPMS, trying to enable JPMS while preserving > > Java 8 compatibility (e.g. with reflection) would have been difficult. > > Can you be more specific? Is there some code we need to produce or > compile that we cannot compile with Java 8? We are still trying to > figure out how to lay out code for multi-module projects. That we > haven't yet figured this out and haven't really needed to. suggests > that maybe multi-module projects aren't all that important in the real > world. JPMS has pretty much failed. It's not clear it was ever needed > in the first place. That said, I would like to be able to support > multi-module builds, but what exactly can't we do without requiring > Java 11? There's plenty of Java 8 code that is fully compatible with > JPMS. There's also some that isn't, typically due to split packages. > However, those problems aren't resolved by upgrading the JDK. In fact, > that's a reason a lot of projects avoid JPMS completely. All that > said, if you can demonstrate in detail that Java 11 is required for > Maven to build projects that use JPMS, and we have a plan for > addressing everything else needed to support multi-module builds, then > I would find that a compelling reason to require Java 11. It isn't > easy though. I took a run at this myself during quarantine and got > nowhere. > > > Java 16+ for starting the migration to records. Some data structures in > > Maven core overlap with Java records. In particular, all the classes > > generated from the `maven.mdo` file, but not only. In short term, > > migrating to records would remove the need to declare constructors, > > hashCode and equals methods, thus making classes simpler and reducing > > the risk of bugs. In medium term, "derived record creation" (currently > > in preview) could replace builders. That would be a massive > > simplification of record-like classes. > > As much as I would like to rip out Modello and chuck it into the > Mariana trench, I don't think that's likely to happen. Consequently > this is a non-starter. If you do manage to rip out and replace > Modello, then we can talk about record classes, but I don't want to > have both Modello and record classes, which is what would likely > happen if we tried this today. > > > Java 24+ (in a later Maven version) for class-file API. It would resolve > > at least some of the compatibility problems observed when new Java > > versions are released and Maven wants to analyse the byte code. > > This one is interesting. Unfortunately it's far too early to require > Java 24+ for users, which is what we'd need for this, since users > would need to run code that calls this API. I don't want to predict > exactly when this will be possible. However, it's multiple years away. > Most big dev shops are extremely slow to upgrade. 3 years ago when I > left Google, they had just finished a multi-year company wide > migration to Java 11. Meta isn't as big a Java shop, but they too were > using Java 11 at least through late 2024. They and others will > eventually get to Java 25, but that's years in the future. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
