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
