Le lun. 15 sept. 2025 à 17:15, Thomas Reinhardt <tho...@reinhardt.com> a écrit :
> > 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" />. > to be the default (ie not have to opt-in it and be smooth for most projects) think it is a good bet on the long run and it doesn't break any project (contrarily to <module> renaming) so all good IMHO > > -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 <gno...@apache.org> a > écrit : > > > >> Le lun. 15 sept. 2025 à 16:08, Alexander Bubenchikov > >> <alexander.bubenchi...@jetbrains.com.invalid> 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 <gno...@apache.org> > wrote: > >>>> > >>>> Le lun. 15 sept. 2025 à 15:41, Alexander Bubenchikov > >>>> <alexander.bubenchi...@jetbrains.com.invalid> 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 <gno...@apache.org> > >> wrote: > >>>>>> > >>>>>> Le lun. 15 sept. 2025 à 14:49, Thomas Reinhardt < > >> tho...@reinhardt.com > >>>>> <mailto:tho...@reinhardt.com>> 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 > >>>>>>>> <nikita.skvort...@jetbrains.com.invalid> a écrit : > >>>>>>>> > >>>>>>>>> Dear developers, > >>>>>>>>> > >>>>>>>>> My colleague, +Alexander Bubenchikov < > >>>>>>> alexander.bubenchi...@jetbrains.com> > >>>>>>>>> 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: nikita.skvort...@jetbrains.com > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >> --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> -- > >>>>>> ------------------------ > >>>>>> Guillaume Nodet > >>>>> > >>>>> > >>>> > >>>> -- > >>>> ------------------------ > >>>> Guillaume Nodet > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >>> > >> > >> -- > >> ------------------------ > >> Guillaume Nodet > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
