desruisseaux commented on code in PR #11702:
URL: https://github.com/apache/maven/pull/11702#discussion_r2812632098
##########
impl/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java:
##########
@@ -692,49 +692,102 @@ private void initProject(MavenProject project,
ModelBuilderResult result) {
}
/*
- * `sourceDirectory`, `testSourceDirectory` and
`scriptSourceDirectory`
- * are ignored if the POM file contains at least one enabled
<source> element
- * for the corresponding scope and language. This rule exists
because
- * Maven provides default values for those elements which may
conflict
- * with user's configuration.
+ * Source directory handling depends on project type and
<sources> configuration:
*
- * Additionally, for modular projects, legacy directories are
unconditionally
- * ignored because it is not clear how to dispatch their
content between
- * different modules. A warning is emitted if these properties
are explicitly set.
+ * 1. CLASSIC projects (no <sources>):
+ * - All legacy directories are used
+ *
+ * 2. MODULAR projects (have <module> in <sources>):
+ * - ALL legacy directories are rejected (can't dispatch
between modules)
+ * - Physical presence of default directories
(src/main/java) also triggers ERROR
Review Comment:
Using the new proposed terminology where "module" = "Java module" and
"sub-project" = "what we were used to call module in Maven 3", then:
* Yes, there is a 1:1 relationship between JARs and modules, i.e. **Java**
modules.
* This is true in all circumstances, both _package hierarchy_ and _module
hierarchy_.
* There is a 1:1 relationship between Maven sub-projects and Java modules
when _package hierarchy_ is used.
* Therefore, there is a 1:1 relationship between Maven sub-projects and JARs
when _package hierarchy_ is used.
* There is no longer a 1:1 relationship between Maven sub-project and Java
modules when _module hierarchy_ is used: a single Maven sub-project can create
many Java modules.
* Therefore, there is no longer a 1:1 relationship between Maven sub-project
and JARs when _module hierarchy_ is used: a single Maven sub-project can create
many JARs.
Package hierarchy is the classical layout of Java source files:
_package/class.java_. Module hierarchy is the same as package hierarchy, but
prefixed with the module name: _module/package/class.java_. Modules hierarchy
are supported by `java`, `javac`, `javadoc` and some other tools (this is not a
concept invented by Maven), sometime with distinct options such as
`--source-path` versus `--module-source-path` (for package and module hierarchy
respectively).
In Maven, the rule is straightforward: if the `<source>` elements contain a
`<module>` child element, then the sub-project uses module hierarchy.
Otherwise, the sub-project uses package hierarchy. There is no special cases or
other complexity, the rule is as straightforward as that.
But another rule is that we cannot mix the two hierarchies: each sub-project
must choose one or the other (but different Maven sub-projects can use
different hierarchy). However, that latter rule was not enforced by Maven core.
If a sub-project breaks that rule, the problem was detected only in the
compiler plugin, sometime only when that plugin tries to pass options to
`javac`. On the principle that errors are easier to resolve when they are
detected early, this pull request tries do detect in advance sub-projects that
would fail to build.
This pull request is not technically mandatory: we could perform no
verification in Maven core and wait for the Maven Compiler Plugin to fail. This
is an attempt to help the users with earlier error report, and also because
Maven core has information that the Maven Compiler Plugin does not have: it is
possible in Maven core to report the exact line in the `pom.xml` where the
problem is detected (although the current pull request does no go that far, but
it can be improved in future cycles).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
