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
