[
https://issues.apache.org/jira/browse/MNGSITE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17907426#comment-17907426
]
ASF GitHub Bot commented on MNGSITE-550:
----------------------------------------
cstamas commented on code in PR #598:
URL: https://github.com/apache/maven-site/pull/598#discussion_r1894104074
##########
content/markdown/whatsnewinmaven4.md:
##########
@@ -0,0 +1,466 @@
+# What's new in Maven 4?
+
+Maven is over 20 years old and is one of the most used build-tool in the Java
world.
+Since all the years one important rule was the highest backward-compatibility
as possible, especially with
+its [POM-schema with Model version 4.0.0][2], used for the build itself, but
also by consumers.
+This made Maven more than a tool, but a whole ecosystem with a lot of things
depended on the POM, esp. the Maven Central
+repository, other build tools and IDEs.
+But this stable schema comes at a price - the lack of flexibility.
+
+> "With the Maven build schema preserved in amber, we can’t evolve much: we’ll
stay forever with Maven 3 minor releases,
+> unable to implement improvements that we imagine will require seriously
updating the POM schema…"
+> — <cite>[Hervé Boutemy (in Javaadvent 2021)][1]</cite>
+
+Maven 4 will prepare to changes which are impossible nowadays, like a complete
new build schema.
+
+Another pain point of Maven 3 is a code base with a lot of deprecated,
convoluted, non performant and duplicated code
+which costs the volunteers who maintain Maven a lot of time.
+This not only means that the Maven codebases contains old Java code that can
be optimized nowadays, but also old
+dependencies and bad API design of its own APIs, especially for Maven plugins.
+Therefore, Maven 4 will also be a maintenance release.
+
+This article presents and explains major changes brought by Maven 4, grouped
into several topics.
+
+## POM-Changes
+
+### Build-POM and Consumer-POM
+
+As written in the introduction the Model version 4.0.0 is used not only for
the build, but also by consumers of the
+artifact.
+But several contents of the POM are only necessary for the build while others
like the dependencies are also needed by
+the consumer.
+Maven 4 will therefore differentiate between a "Build-POM" and a
"Consumer-POM".
+As names suggest the "Build-POM" will contain all information needed for to
build the artifact, e.g. used plugins and
+their configuration, while the "Consumer-POM", which is created during the
Maven build, will not contain those.
+This POM will only keep those which are really needed to use the artifact,
e.g. dependency information.
+
+**Note**: See below for a comparison of the content of both POMs.
+
+### Model version 4.1.0
+
+With now having two types of POM Maven 4 can already make additions to the
Build-POM as it will only be used by Maven (
+and of course IDEs).
+Therefore, with Maven 4 a new Model version 4.1.0 is introduced.
+This version introduces some new elements and attributes, while others got
marked as deprecated.
+To not break the ecosystem this version is only available for the Build-POM,
while the Consumer-POM will still use
+version 4.0.0.
+This means Maven will generate the Consumer-POM during the build.
+
+**Note**: Maven 4 will of course continue to build your model version 4.0.0
project!
+There is no need to update your POMs to 4.1.0 as long as you don't want to
make use of the new features.
+But as like every software update - it's suggested to update them to 4.1.0,
e.g. to avoid problems when deprecated
+things get removed in future updates.
+
+### Modules are now subprojects
+
+From the early days of Maven 1 till today, all build information is stored in
the POM, short for "Project Object Model".
+Together with build folders and other files the wording "Maven project" is
used.
+However, project containing multiple parts, e.g. an API and a client, each of
those parts was called "module" and listed
+in the `<modules>` section of the POM, leading to the terms of "multi-module
project".
+This wording introduced some inconsistency, especially as projects with any
`<modules>` section are often called "
+single-module".
+Since the introduction of the [Java Platform Module System][3] in Java 9 the
term "module" raised additional confusion.
+
+Maven 4 gets rid of this by naming "modules" as what they are - subprojects.
+Model version 4.1.0 contains a new element `<subprojects>`analogous to the now
deprecated, but still usable, element
+`<modules>`.
+
+**Note**: It's suggested to use the terms `multi-project setup` and
`single-project setup` to differentiate between a
+Maven project with or without subprojects.
+
+### New packaging type: bom
+
+Maven 4 introduces a dedicated packaging type to provide a [Bill of Material
BOM][4] called "bom" to differentiate more
+precisely between "parent POMs" and dependency managing BOMs.
+While the new type is only available with model Version 4.1.0 the final
outcome is a full Maven 3 compatible (model
+4.0.0) POM file!
+For an example see the link above or
+the [live coding by Maven maintainer Karl Heinz Marbaise at IntelliJ IDEA Conf
2004][5].
+
+**Note**: With Maven 4 it's also possible to exclude dependencies which are
declared by BOMs using the existing
+`<exclusions>` element.
+Also note that in Maven4 importing BOMs with classifier is now possible.
+Therefore, Maven team suggests that projects BOMs be generated as classified
artifacts (see Maven build "skinny" vs "
Review Comment:
Our stance (@gnodet could chime in when online) is following: BOMs should be
_generated_ and not used within reactor (see issues), because users are
"tempted" to create BOMs within reactor (is fine, as long BOM is "published
only"), and then reuse BOM in same way as any external BOM would be reused: by
importing within reactor. But, importing within reactor causes "build
peculiarities" usually unexpected to users. Hence, we think that _generating
BOMs_ simply prevents the two issues, as reactor dependendencies should be
managed using inheritance, as it was always the case with Maven. Appearance of
BOMs simply caused this "boost of creativity", to reuse them within reactor,
but also publish them to downstream users, and it is wrong. Hence, Maven 4
shows an "example", and generates it's own BOMs. Related
https://issues.apache.org/jira/browse/MNG-8012 and
https://issues.apache.org/jira/browse/MNG-8009
In short: only external BOMs should be imported to reactor.
As per "what is a BOM", there is a split among us as can be seen in this old
PR: https://github.com/apache/maven/pull/689
For some, "[BOM represents only the set of modules of a
multimodule](https://github.com/apache/maven/pull/689#issuecomment-1061640064)"
(only the reactor, so to say) while for others (@gnodet and me included) "BOM
is bill of materials", so full stack: if I do an extension for Maven version X,
I want same version of Resolver, Logging, Sisu etc that Maven X use as well...
Similarly, look at all our plugins: after version property defining Maven
version that plugins builds against, property is usually followed by a section
with bunch of "keep in lockstep with Maven" version properties for logging,
resolver, etc. All this is just noise and should not be needed. Hence, the
"skinny" (first definition) vs "fat" (second definition). In fact, Maven4
generates both now, so pleases both parties.
Of course, Maven 4 build generated BOMs can be used only in Maven 4 builds,
as only Maven 4 allows importing BOMs with classifiers... So for Maven3, this
is still an issue.
> Information about "What's new in Maven 4?"
> ------------------------------------------
>
> Key: MNGSITE-550
> URL: https://issues.apache.org/jira/browse/MNGSITE-550
> Project: Maven Project Web Site
> Issue Type: Improvement
> Reporter: Matthias Bünger
> Priority: Major
>
> A comprehensive article/list of the important changes in Maven 4 is needed.
> ----
>
> Issue based on the slack message / thread, started by [~cstamas]
> {quote}
> More and more times we get questions like "and what is new in Maven4?". We
> have no document that distills the relevant changes. Could someone try to
> collect that in cwiki or somewhere?
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
