Define versioning policy?

[rmannibucau]

Hi all,

Is it possible to get some versioning policy around mvnd.
Statements I would expect are:

1. is it using semver (if not what does mean major/minor/patch)
2. how does it follow maven and how does it relate to? ("it follows each minor of 3.x and there is a compatibility matrix for the equivalence" or "it is compatible with 3.x and rely on the env maven" kind of statement - I know both are not accurate as of today but just trying to illustrate the idea)
3. Any plan to support multiple maven branches?
4. What about security fixes in mvnd or maven stack?

Thanks.

[gnodet]

Hi all,

Is it possible to get some versioning policy around mvnd.
Statements I would expect are:

1. is it using semver (if not what does mean major/minor/patch)

We've been trying to follow semver, at least for minor/patch (we haven't done any major...)

2. how does it follow maven and how does it relate to? ("it follows each minor of 3.x and there is a compatibility matrix for the equivalence" or "it is compatible with 3.x and rely on the env maven" kind of statement - I know both are not accurate as of today but just trying to illustrate the idea)

That's definitely a problem. See below.

3. Any plan to support multiple maven branches?

See #384. My original idea was to be able to support multiple maven versions managed from the same mvnd version. Kinda like daemons are spawned according to the JDK, they could be spawned according to the maven version as an additional discriminating parameter (along with the JDK, the JVM options, etc...). I do need to find some time to work on that. It may need a few different implementations of the DaemonMavenCli based on which version of maven is used, but that could be one module for each maven version/branch we want to support.
This would also require some change to the distribution layout to accommodate multiple maven versions.

4. What about security fixes in mvnd or maven stack?

Currently, rolling up patches is quite easy. We haven't been back porting anything at this point. Patch releases only occur on the current master branch. For maven, we didn't had the problem until 3.8.1, which also contains a breaking change, so it's a bit complicated.

Thanks.

[rmannibucau]

I see, is it possible to get a wiki page writing at least the semver point and that the maven relationship is "in progress" (I guess it is fine while 0.x but hope it will be clarified for >= 1.x).
If mvnd can a bit decoupled from a maven version I guess it will be simpler since it will only be about mvnd and therefore semver can be enforced so maybe let's wait for this feature to finalize this policy and close this issue?

[lanmaoxinqing]

See #384. My original idea was to be able to support multiple maven versions managed from the same mvnd version. Kinda like daemons are spawned according to the JDK, they could be spawned according to the maven version as an additional discriminating parameter (along with the JDK, the JVM options, etc...). I do need to find some time to work on that. It may need a few different implementations of the DaemonMavenCli based on which version of maven is used, but that could be one module for each maven version/branch we want to support.
This would also require some change to the distribution layout to accommodate multiple maven versions.

for version below 3.3.x, a ton of works needs to be done.
CoreExtension, ProjectArtifact, ExtensionRealmCache, PluginRealmCacheEventSpy was not supported, CliRequest, CommandLineBuilder was privated, MavenCli and MavenPluginManager was also different :-<

[rmannibucau]

Guess >= 3.6 is sufficient no?

[gnodet]

I just saw that when integrated into the maven codebase, the maven wrapper was tightly coupled to maven. The old wrapper could work on top of existing maven distribution, but the new one can not. If being able to support old maven versions is never a goal of the maven team, I'm not sure why we should spend too much time on that. @rmannibucau ?

[rmannibucau]

Because maven will deliver the wrapper with each version, potentially of all branch. If each new maven release gets a mvnd matching release it just needs a versioning standard definition but works too.

[hboutemy]

I just saw that when integrated into the maven codebase, the maven wrapper was tightly coupled to maven.

notice that this aspect has been fully removed in wrapper 3.1.0 MWRAPPER-14 in December 2021, because as you saw, it caused many issues: current wrapper 3.1.0+ https://maven.apache.org/wrapper/ can download any Maven release

[rmannibucau]

But not yet mvnd so either we add it to the distro, we update it, we add alazy download to the distro or something else but right now mvn and mvnd are not consistent in our ecosystem IMHO and we could do better for users.

[hboutemy]

I don't want to have mvnd automatically downloaded by wrapper: I want mvnd client/server architecture to be able to run with any Maven version (with eventually some compatibility limits)

[rmannibucau]

@hboutemy ok so what would be the plan, mvnd downloads mvn (so it stays another distro but adds some download capacity - potentially just using jre httpclient since nobody runs it on java 8 probably to stay light), we create one bin per version+bundle it in mvn then mvnd relies on the existing one (the opposite requiring to release mvnd with new mvn versions so not solving the issue)? This issue is almost 2 years old so thought it would be easier to couple them but if you think we can avoid it +1 while it does not enforce to download mvnd+mvn manually for each upgrade.

[gnodet]

I don't want to have mvnd automatically downloaded by wrapper: I want mvnd client/server architecture to be able to run with any Maven version (with eventually some compatibility limits)

Most of the performance improvements come from the ability to customise the maven and this requires tight integration for now. At beginning, mvnd had to rewrite a bunch of maven classes. The number slowly goes down, but it will be difficult to have mvnd be independent on maven until we have such things. The most important point remaining is the DaemonMavenCli which is a pain to maintain.

What could be done, is to have different versions of mvnd-daemon module for each specific version of maven and use the correct one depending on the maven version used.
For example, we have these changes to go from 3.x to 4.x. Not sure how far we can go in this direction, but this would be a first step at supporting multiple versions of maven.
From a distribution point of view, I'm not sure if we can actually avoid embedding maven in the mvnd distribution.
Another point would be how to select the maven version to run ? Would we need something like what the maven-wrapper does ? i.e. specify the maven version for a given project ?

I was planning at releasing a mvnd 0.9.x to support maven 3.8.7.

At the end, I'm not sure if it's easier to maintain multiple branches of mvnd focused on different version of maven, or to try to support them all in a single branch... At this point, I'm leaning toward the first solution because it's much less time consuming I think.

[rmannibucau]

Think the easiest is to release both at a single distribution then we can propose at download current distro or another distro with mvn + mvnd, sounds the simplest for us on the long run.
Making it pluggable means at some point user will still download mvn+mvnd which is what nobody wants from what I understand.

[gnodet]

Well, mvnd already bundles maven. You can run it with [mvnd-home]/mvn/bin/mvn. So I don't think there's a need for another mvn + mvnd distribution, as it already exists.

[rmannibucau]

@gnodet the need is to get all scripts in bin/ to add a single dir to PATH but more than fine for me to 1. rework the distro layout and 2. add the link on https://maven.apache.org/download.cgi