I think <subprojects /> definitly should disable discovery. A list of
submodules *was* specified (with 0 actual submodules).
Also, sorry if this was discussed before, but why is auto-discovery the
default? It could be off by default and who wants it can enable it with
something like <subprojects auto-discovery="true" />.
-Thomas
Mit freundlichen Grüßen,
Thomas Reinhardt
On 15/09/2025 16:22, Romain Manni-Bucau wrote:
Maybe we can consider empty is defined (even if defined as null) so do not
discover else discover.
Also think the last example is exactly what we do want for maven 4 since if
the module doesn't use explicit declaration it will define all modules in
the profile.
Romain Manni-Bucau
@rmannibucau <https://x.com/rmannibucau> | .NET Blog
<https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old
Blog <http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064>
Javaccino founder (Java/.NET service - contact via linkedin)
Le lun. 15 sept. 2025 à 16:21, Guillaume Nodet <[email protected]> a écrit :
Le lun. 15 sept. 2025 à 16:08, Alexander Bubenchikov
<[email protected]> a écrit :
The choice needs to be deterministic and not depend on whether someone
defines a profile in settings. So the rule is not to check in
effective
profiles, but in the profiles defined *in the current POM*.
I see your point, but Im afraid the current approach does not look fully
deterministic.
For example, consider the project - pom.xml, m1/pom.xml, m2/pom.xml,
where
the parent pom does not contain <subprojects> section
Then both modules will be automatically included into the build, unless
profile
```
<profile>
<id>one</id>
<activation>
<activeByDefault>true</activeByDefault>
<activation>
<subprojects>
<subproject>m1</subproject>
</subprojects>
<profille>
```
Is defined.
If the profile is defined in the parent pom, the two subprojects would not
be discovered. If that profile is defined in settings.xml, it would be
ignored, and the discovery would happen anyway.
When I say deterministic, I mean that user settings should not affect the
behavior. And that is also independent of any profile activation. It's
only based on the content of the current pom.xml, nothing else.
We could agree to ignore such case, but still - the behaviour of
inclusion
depends on the effective profile, not the defined one.
May be it would also make sense to restrict profiles declared in
settings.xml and not allow such “global” profiles to include submodules,
wdyt?
On 15 Sep 2025, at 3:47 PM, Guillaume Nodet <[email protected]> wrote:
Le lun. 15 sept. 2025 à 15:41, Alexander Bubenchikov
<[email protected]> a écrit :
I don’t think you should verify whether there are profiles which
define
subprojects.
There could be profiles defined elsewhere - in parent, in
settings.xml,
profiles.xml, I’m afraid this could make the behaviour really weird
from
user POV.
The choice needs to be deterministic and not depend on whether someone
defines a profile in settings. So the rule is not to check in
effective
profiles, but in the profiles defined *in the current POM*.
What do you think about distinquishing cases with absent <subprojects>
tag
and empty (<subprojects/>) one to disable scanning - in the same way
it
is
done with <relativePath>?
Unfortunately, we can't easily do that, as we can't have null lists in
the
model (those are transformed into empty ones).
Thanks, Alex
On 15 Sep 2025, at 3:11 PM, Guillaume Nodet <[email protected]>
wrote:
Le lun. 15 sept. 2025 à 14:49, Thomas Reinhardt <
[email protected]
<mailto:[email protected]>> a
écrit :
Wow, I missed that one.
I'm not sure I like this kind of automatism (module discovery).
Maybe this also breaks some plugins? For example: I have more than
one
custom plugin that simply reads the root POM and extracts the
modules
for further processing. Of course that also ignores modules in
profiles
so maybe a non-issue there. I have to think more about this.
Also, seems to be a good way to slow down your builds. Scanning
directories is somehow expensive on some platforms.
It's only direct subdirectories (first level) which are scanned, so
it
cannot be insanely slow.
But if I am stating a <modules> (or the now preferred <subprojects>)
section in my root POM this behavior is disabled and only my
actually
defined modules/subprojects are considered, right?
This is not specific to the root POM. But yes, this behavior won't
kick
in
for a given POM
* if you have any explicit list of subprojects/modules in the POM
* or if the modelVersion is 4.0.0
* or if the packaging isn't `pom`
The second assertion makes sure it cannot break existing Maven 3
projects.
But as I said, it's missing a verification that no profiles on this
POM
defines a subproject/module.
THis is required in order to be able to activate some subprojects
using
profiles, without having
any default subprojects when not using any specific profile.
Greeings,
Thomas Reinhardt
On 15/09/2025 11:02, Guillaume Nodet wrote:
I just replied on the issue. This is the expected behavior for:
* 4.1.0 models
* which have a `pom` packaging
* which defines no subprojects/modules
In such cases, all direct subdirectories which contain a pom will
be
considered as subprojects.
However, I think the original idea of the rule `which defines no
subprojects/modules` was to also check for profiles, else, there
would
be
no way to actually enable/disable some subprojects based on a
profile,
which may be what #11114 is about.
Le ven. 12 sept. 2025 à 16:24, Nikita Skvortsov
<[email protected]> a écrit :
Dear developers,
My colleague, +Alexander Bubenchikov <
[email protected]>
discovered an interesting behavior of Maven 4.0.0-rc-4. In short,
Maven
picks up subprojects from subdirectories *without any
modules/subprojects
definition* in pom.xml (reported as #11114
<https://github.com/apache/maven/issues/11114>).
Is it an expected behavior?
---
Nikita Skvortsov
Java Build Tools Team Lead
JetBrains N.V. | KvK reg. nr. 56460279
Gelrestraat 16, 1079 MZ Amsterdam, The Netherlands
T: + 31 (0)20 205 01 18 | F: +31 (0)20 205 01 19
E: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
------------------------
Guillaume Nodet
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
