[MNGSITE-550] What's new in Maven 4?

[Bukama]

This PR adds an article about the major changes in Maven 4.

[Bukama]

Info:

• I put the article quite on high in the menu to make it more visible. When Maven 4 grew up a bit it can be (re-)moved.
• I manually edited the site.xml to not apply full code style changes as it's not correctly formatted as of now (see #MNGSITE-539 Formatting the affected files #595)

[Bukama]

Thanks for the feedback and the editing @gnodet!

[Bukama]

Hope everything is fine now :)

[elharo]

I'm not sure this is true. If it is, elaboration is needed.

[Bukama]

I'm not sure this is true. If it is, elaboration is needed.

@cstamas @gnodet Can you give us some insight please?

[Bukama]

Thank you for your feedback @elharo! Integrated all of your text suggestions and left the two questions/doubts for further responses/discussion - I'm open to everything.

[Bukama]

Consider the audience of this document. This simply is not relevant to someone who simply wants to use Maven to build their code. It's only relevant to the people developing Maven and that's not who this is written for.

I slightly disagree on that: The audience of this document are all Maven users - those who only want to run their build, but also those who want to know more about the changes, are responsible for build management in their teams, etc (I think someone called them "power users"). If we only considers those who "blindly" use Maven, we don't need the article at all. They are those who still run Maven 3.3.9 and mvn clean install because that's what they've read in a tutorial or what was told them years ago.

I'm not sure we can expect people reading this document to already know the difference between build and consumers. This should probably be carefully explained right up front.

What do you think about

Throughout the years, one important rule has been maintaining the highest backward compatibility possible, especially with its [POM-schema with Model version 4.0.0][2].
This is very important, because POM files with this schema version are not only used for the build of the own project.
Projects, using 3rd party libraries, also rely on the POM files of those, as it contains information needed to successfully run their own builds.
Those projects are called "(a dependency) consuming projects".

Also, "consumers" is a strange term here. I might consider dependents instead, but either way it does need to be defined.

Used the term "consumers" due the terms the committers introduced when developing this feature.

[Bukama]

@elharo Thanks for your feedback again. I don't know why I have not seen it 4 days ago :O Think I went through all of them, except the subproject renaming. Might have another look at it tomorrow (I'm too tired for that now).

[slachiewicz]

do You have plan to publish it now or when 4 is released?

[Bukama]

do You have plan to publish it now or when 4 is released?

I would like to release it now, as a) @cstamas said we get asked what changes more often and b) several of us (e.g. Maarten, Karl Heinz, Robert, me) give talks about that quite a long time, but it's always too less time on conferences or many JUG to cover all.

[elharo]

Where else are these terms defined?

[elharo]

is session the actual execution of a Maven build or the
current working directory? Or does this sentence need to be rephrased?

[michael-o]

Removing myself since I don't have the capacity to review such large PRs.

[elharo]

This doesn't say that the namespace is changing from http://maven.apache.org/POM/4.0.0 to http://maven.apache.org/POM/4.1.0. IMHO it shouldn't be changing and I'm hopeful this change can be reverted. Mixing versions into namespace URIs is a known XML antipattern. But if it's in play it is a huge change that should be called out here.

[gnodet]

This doesn't say that the namespace is changing from http://maven.apache.org/POM/4.0.0 to http://maven.apache.org/POM/4.1.0. IMHO it shouldn't be changing and I'm hopeful this change can be reverted. Mixing versions into namespace URIs is a known XML antipattern. But if it's in play it is a huge change that should be called out here.

What are you referring to exactly ?

[elharo]

For this PR it should call out that the namespace used to be http://maven.apache.org/POM/4.0.0 and is now http://maven.apache.org/POM/4.1.0

For the general Issue I filed a bug in Jira with more details. Versions in namespace URIs is an antipattern, though a common one.

[Bukama]

For this PR it should call out that the namespace used to be http://maven.apache.org/POM/4.0.0 and is now http://maven.apache.org/POM/4.1.0

Mentioned the new namespace in the Model 4.1.0 section

rereading

[kwin]

mvnenc is just a frontend, the underlying backend is rather https://github.com/codehaus-plexus/plexus-sec-dispatcher. Compare with #654.

[cstamas]

I would not go into this distinction: plexus-sec-dispatcher is NOT an API, is not something people should use or reuse or even made aware. We already had problems with it in Maven3.

[kwin]

But

based on Maven Encryption (mvnenc) - a standalone CLI tool.

feels wrong to me. I would rather remove the sentence then altogether.

[kwin]

So what API is proposed by Maven for sensitive values e.g. for Mojos or extensions?

[elharo]

"plexus-sec-dispatcher is NOT an API, is not something people should use or reuse or even made aware. " -- Hyrum's Law rides again

[Bukama]

But

based on Maven Encryption (mvnenc) - a standalone CLI tool.

feels wrong to me. I would rather remove the sentence then altogether.

The phrasing is based on @cstamas blog about it:

Maven4 password encryption is handled by the new CLI tool: mvnenc.

Shall I add a link to https://maven.apache.org/guides/mini/guide-encryption.html here, because that's the guide about encryption, which can (or should) hold the details.

[lbruun]

Inference of <modelVersion> is another new feature in Maven v4. You may want to add that.

Doing

<project xmlns="http://maven.apache.org/POM/4.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.1.0 https://maven.apache.org/xsd/maven-4.1.0.xsd">
  <modelVersion>4.1.0</modelVersion>
</project>

is no longer necessary: you can leave out the <modelVersion> element and it will be inferred from the XML ns.

The below is equivalent to the above:

<project xmlns="http://maven.apache.org/POM/4.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.1.0 https://maven.apache.org/xsd/maven-4.1.0.xsd">
</project>

(no <modelVersion> element)

[gnodet]

that feature has been challenged by https://issues.apache.org/jira/browse/MNG-8537

[Bukama]

that feature has been challenged by https://issues.apache.org/jira/browse/MNG-8537

I'm aware of this issue and as far as I understand the discussion it's also the cause why this PR does not move forward. Maybe I should even close it completely. It's open for about 6 weeks now, some don't want to review it cause if its size and as long as it's open from time and time someone sneaks in to request documentation which should be in the explicit pages but not in a summary (@lbruun I don't mean you by this, your ping about the not necessary <modelVersion> is totally fine and I would instantly add it, if MNG-8537 would not exists/be closed).