The future evolution of m2eclipse

[laeubi]

Now with Maven 4 approaching on the horizon we need to think how to handle the future of m2e with these many changes internally and externally. Our goal is to handle this as graceful as possible, but due to how m2e internally works it will not be possible to offer both 3.x and 4.x at the same time in full parallel without completely rewriting m2e from scratch.

Because of this we now have made the following plan for the future evolution of m2e

1. There will be a maintenance branch with the current 2.x, and we will use it to publish new runtimes of Maven 3.x, but development and cadence might depend on community support and will likely not receive any new features.
2. The main branch will become a new major version for the "marketing version" that is we likely will change the features to 3.0 but keep the bundle versions at 2.x with the new usage of +100 increments. In some circumstances we might still raise bundle versions if required. We will then make Maven 4 the default runtime with the option to install the latest 3.9.x runtime, all previously older runtimes support will be dropped (e.g. 3.8, 3.7 and so on)! As many things are deprecated in Maven 4, we will likely face a lot of deprecation warnings but this seems required for the transition period. Also this will be a good opportunity to switch from the old plexus-build api to the new 1.0 version as there should be enough time for bundles to adapt and this will become the new future for IDE integration of plugins.
3. At some time, when Maven 4 has become de-factor mainstream, we will start a m2e 4.0 release, removing all deprecated code and dropping Maven 3.x support entirely as a consequence.

Please feel free to share any thought here, this is currently just a first idea an nothing is set in stone.

[danthe1st]

Is this something where a heads-up should be given in Eclipse mailing appropriate mailing lists that might benefit from it (such that people working on other Eclipse projects know about it) and possibly some other places before the change is actually being done (maybe this should be mentioned in this week's devcall @HannesWell)?

Also, does it make sense to make the 3.x version available optionally first (not included by default) with a N&N entry and maybe even one of the oomph notifications telling users about this change? I guess it would be good to decide on a plan/roadmap for simrel (I guess an "optional" installation can be made available whenever it is done).

[laeubi]

I have rather bad experience with "not enabled by default"... most users simply don't test it. So the other way round, enabled by default with an option to disable it is usually much more promising. Also maven itself is often not a large topic on the dev-calls but why not. In the end there is much work to be done and we either need contributions from users or funding from the IDE-WG or companies interested in maven 4... right now most people seem happy with status-quo.

[danthe1st]

One remaining thing to consider is how long the 2.x branch should receive necessary updates (backporting important bugfixes). As Maven 3.8 seems to still receive updates as of writing this comment, it might make sense to keep 2.x up (in maintainance mode) at least as long as Maven 3.8 is receiving updates (idk how long that will be but this might not be an issue if they only support the latest two minor versions?).

Similarly, for the question of how long to wait until a 4.x release that drops Maven 3 support, it might make sense to wait at least until 3.9 is EOL.

[maxandersen]

Given how massively used maven is - shouldn't it be explored that m2e for m4 would be a different namespace so users could have them coinstalled even if no updates ?

[laeubi]

Given how massively used maven is - shouldn't it be explored that m2e for m4 would be a different namespace so users could have them coinstalled even if no updates ?

Given that only very few people ever contribute (compared to "how massively used maven") its unlikely we can afford such efforts.

[maxandersen]

I get its not easy; but given eclipse-m2e is about supporting maven and it is a expected that we will see maven3 projects for a long long time - shouldn't we at least look at enabling co-existence instead of "only maven4 support now" ?

If I misunderstood the issue and even if we upgrade to maven4 users can still work with maven3 projects then all good...but if not - then such an event where the ecosystem has a time where users will be split it seems worthwhile at least enabling contributors stuck on mvn3 or need to use both to actually be able to contribute to the project.

[maxandersen]

just re-read the various issues and I see that expectation is that one install of m2eclipe will work with both mvn 3.9 and 4.x - that is more than enough and I agree if that is expected to work then those on older mvn's should either update to mvn 3.9 OR install older m2eclipse.

i just read on first through as that even mvn 3.9 would not likely work which would be problematic if no way for users to contribute to fix without loosing mvn4 support.

[danthe1st]

If I misunderstood the issue and even if we upgrade to maven4 users can still work with maven3 projects then all good...but if not - then such an event where the ecosystem has a time where users will be split it seems worthwhile at least enabling contributors stuck on mvn3 or need to use both to actually be able to contribute to the project.

In most cases, you can use Maven 4 with a Maven 3 project/POM and everything is fine. For some projects/with some Maven plugins, there might be some problems with plugins using APIs that no longer work but that should be the exception rather than the rule (for example, you cannot build Eclipse/Eclipse Plugins with Maven 4). I am using Maven 4 already to build most projects.
However, many people are using old Maven versions and not being able to run them could remind them that they should at least update to Maven 3.9.