We should be talking about consistency. We have a flag --non-recursive, which implies that recursive is the default. With Maven 3 that is just not always the case and this should be fixed. Maven 4 is the right version to do so.
Using -pl <arg> -N does not work with Maven 3: it'll say "Couldn't find the selected project in the reactor" Being able to use this combination AND making -pl recursive by default makes everything consistent. The argument that this change will break backwards compatibility is less important to me and is actually not true. By switching to recursive by default and calling -pl <module> it will still build the module ... and more. We're not building less! The question you need to ask yourself every time in case of a pom packaged project: Do I want to build the parent? call -pl <arg> -N Do I want to build the aggregated modules call -pl <arg> Consistency is key: ensure that you can always add --non-recursive/-N. This will always and only build the selected projects, no exclusions, and otherwise it'll be recursive. Robert On 26-2-2021 14:45:18, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: Le ven. 26 févr. 2021 à 14:30, Robert Scholte a écrit : > This discussion is about aggregators, and not about parent. > Quite often an aggregator is also the parent of its modules, but that is > not required. > Ack > > Calling -pl with Maven3 behaves unnatural: if you want to > call a specific aggregator, you want its modules to be built. > I disagree, it looks unatural if you know it is an aggregator but there is no way to know form maven standpoint, it is a pom which children and with packaging=pom which does not mean it is an aggregator. To give a quick example of that: the strict aggregator case will desire to build children but not the aggregator itself (functionally) whereas all other cases want the pom itself. > > Hence I still support the change to make this the default behavior. > > In those rare cases where you want to build it only because it is a parent > (and not for the aggregator part), it makes sense to add --non-recursive > It is not rare, it is actually very very common to use it as a prestep on CI builds and the new behavior break it all. Since the value of pl is already an expression ([groupId]:artifactId), it is saner to use it and enrich this semantic to support "project with child" meaning for end users IMHO. > > All the options you had in Maven 3 for selecting a subset of a multimodule > project are still available in Maven 4. > Maven 4 is not an opportunity to break existing builds IMHO, it would deserve maven, it is an opportunity to break internals and build pipeline for sure. > > To me the new behavior is much better. Maven 4 is the perfect version to > introduce these changes. > > thanks, > Robert > > > > > On 26-2-2021 14:02:29, Romain Manni-Bucau wrote: > I still think it is wrong to have such a global toggle + break backward > compatibility (-pl + -N is *already* used for what it is today which is not > the proposal but -pl parent without -N is also already used and works > well). > You can also take into consideration that -pl -module -N meaning is > completely broken with this new definition. > For these 3 reasons I think we shouldn't break current API and either add a > new toggle/syntax (>parent or !!parent or whatever forbidden character in > module names/folder fits you) or not do anything since nothing prevents to > build a subtree with -pl as of today, it is just a bit more verbose than a > single module selection. > > Romain Manni-Bucau > @rmannibucau | Blog > | Old Blog > | Github | > LinkedIn | Book > > > > Le ven. 26 févr. 2021 à 13:16, Martin Kanters a > écrit : > > > I've had a talk this morning with Robert Scholte and Maarten Mulders > about > > this, since I had the feeling we were not getting further in this mail > > thread. > > > > First of all, we all agreed that we definitely needed functionality for > > both recursive and non-recursive project selection. What Robert prefers > is > > the following: reusing existing flags if possible and no extra magic in > the > > -pl syntax. So that boils down to "-pl + -N". By default, project > selection > > will be recursive and by passing -N to it, it will be switched to > > non-recursive. > > > > While first I was hesitant on this solution, I realize now that this is > the > > most user-friendly solution. Technically -N might mean different things > > when used with and without -pl, but functionally it's the same. > > > > Two points of concern were: > > - "it's a global switch, we cannot select a recursive and non-recursive > > project in one maven-command". That's true, but that's currently also not > > possible in 3.6.3 (automatically) and we should find the balance between > > usability and ensuring every possible scenario is possible. > > - "it might cause a performance degradation". This is not true when the > > current behavior of -N will only change when used together with -pl. > > > > We’ll continue work in this direction. Feel free to raise any new > concerns > > if they arise. > > > > Martin > > > > Op zo 21 feb. 2021 om 22:29 schreef Romain Manni-Bucau > > rmannibu...@gmail.com>: > > > > > Put some comments inline but agree another minilanguage solution works. > > > Maybe -pl !!parent? > > > > > > Le dim. 21 févr. 2021 à 22:08, Martin Kanters > > a > > > écrit : > > > > > > > Romain: 2 has overlap if I'm not mistaken, what if the user invokes: > > mvn > > > > -pl project-a -plr !project-a. Perhaps the user should be able to > only > > > > select aggregator poms via -plr.. > > > > And I'm not sure how the alias function would work. I assume > something > > > > like: > > > > > > > > > > Yes but same as today with -pl foo -pl!foo. We can fail in such a case > > too > > > (my preference). Then more specific wins, ie -plr parent -pl > !parent/foo > > is > > > obvious. > > > > > > > > > - pom.xml config (psuedo code): -pl parent, submodule-a, > > > > submodule-b, submodule-c > > > > - invocation mvn alias:rec. > > > > If that assumption is correct, the user would have to manually > maintain > > > the > > > > list of modules of "parent", while Maven can do this perfectly. > > > > > > > > > > Right, is it an issue? I dont think. Opposite is true too, you need to > > > maintain children exclusions in general (all but "build" child module > or > > > all but front or all but doc etc) so 1-1 IMHO. > > > > > > > > > > Falko: I don't intend to drop the recursive behavior either :) > > > > I don't dislike the idea of adding a suffix to a project to include > > > > everything recursively and + might fix the shell expansion issue > > (which * > > > > has). > > > > I guess this might be a nice alternative as well, but I'm not sure if > > > > everybody likes increasing the complexity of the -pl syntax. "-pl > > > !?proj/+" > > > > or "-pl !?group:artifact+" is starting to look a bit like magic.. :) > > > > > > > > > > Martin > > > > > > > > Op zo 21 feb. 2021 om 21:38 schreef Falko Modler : > > > > > > > > > My 2 cents: Please don't drop the recursive behavior again because > it > > > is > > > > > really useful! > > > > > > > > > > Crazy idea (just brainstorming here): > > > > > -pl foo builds only foo > > > > > -pl foo+ builds foo and its children, wherever they are exactly > > > > > > > > > > This would also co-exist with the ! and ? prefixes. > > > > > > > > > > PS: Since if often use shell path completion, -pl foo/+ should have > > the > > > > > same effect, ideally. > > > > > > > > > > Cheers, > > > > > > > > > > Falko > > > > > > > > > > Am 21.02.2021 um 21:09 schrieb Romain Manni-Bucau: > > > > > > Le dim. 21 févr. 2021 à 20:39, Martin Kanters > > > > martinkant...@apache.org> > > > > > a > > > > > > écrit : > > > > > > > > > > > >> Hm, so I guess that's indeed a valid reason to keep the old > > > > > functionality > > > > > >> working. Thanks for the enlightenment, Romain. > > > > > >> Still I think it makes more sense to make project selection > > > recursive > > > > by > > > > > >> default, but it's not straightforward to come up with a nice > > > > > combination of > > > > > >> flags. > > > > > >> Let's summarize: > > > > > >> > > > > > >> 1. -pl + -N: > > > > > >> While it does sound like the flag to re-use, I do not like the > > fact > > > > > that -N > > > > > >> works differently than normal when used together with -pl. The > > code > > > > > would > > > > > >> become more complex and the flag hard to explain to users. > > > > > >> > > > > > > Does not really solves the issue as soon as you use it for 2 > > > different > > > > > kind > > > > > > of modules until it becomes -plN which is 4 IMHO > > > > > > > > > > > > > > > > > >> 2. -pl + -plr: > > > > > >> This gives the most flexibility, giving users the option to > select > > > > > >> non-recursive and recursive projects in one command. The two > flags > > > > have > > > > > a > > > > > >> lot of overlap though, what happens when a project is selected > > with > > > > -pl > > > > > and > > > > > >> deselected with -plr, which gets precedence etc. > > > > > >> > > > > > > -plr without -pl, dont use a global toggle probably. > > > > > > > > > > > > Ex: -pl parent-with-plugins -plr myaggregator -pl foo/bar -plr > > > > > docker-images > > > > > > > > > > > > > > > > > >> 3. -pl /* > > > > > >> This gives the same flexibility as 2, but then in one command. I > > do > > > > like > > > > > >> that, but it can get messy with shell expansion. One other thing > > is > > > > that > > > > > >> with -pl you can select projects using the directory, but also > by > > > > > >> (optionally groupid and) artifactId. The star (or its > replacement) > > > > could > > > > > >> mean different things when used in either variant. Mind that > > > > submodules > > > > > do > > > > > >> not have to be placed directly in a subdirectory. > > > > > >> > > > > > > Other issue is maven works with not linear (tree) children so can > > be > > > > > > complex to handle when parents or children are in other physical > > tree > > > > or > > > > > > even projects. > > > > > > > > > > > > > > > > > >> 4. (new idea) -pl + --pl-non-recursive: > > > > > >> This does not have the flexibility 2 and 3 provides and we would > > > have > > > > to > > > > > >> introduce a new CLI flag. But it does have a very clear goal > which > > > is > > > > > easy > > > > > >> to implement + explain. > > > > > >> > > > > > > Hmm another global toggle? It will have the same combination > issue > > > than > > > > > -N > > > > > > IMHO. > > > > > > So overall this sounds like reversing -pl and adding this > > > complementary > > > > > > option so 2 sounds the saner equivalent option for backward > compat. > > > > > > > > > > > > > > > > > >> 5. Revert all and restore 3.6.3 functionality. > > > > > >> Users could build extensions or plugin functionality to achieve > > the > > > > > >> recursiveness. Not my favorite, because I think this is > something > > > > Maven > > > > > >> Core should be able to provide out of the box. > > > > > >> > > > > > > "Extension" can be built in too, just mentionned we can solve it > > > > > > differently than enriching again the cli since functionally we > > > already > > > > > > cover it. > > > > > > > > > > > > > > > > > >> 6. Make recursiveness the default and do not provide a > workaround > > > for > > > > > >> non-recursiveness > > > > > >> Since we are going to a new major version it's acceptable to > > > > > break/change > > > > > >> existing behavior. We could wait until users complain and then > > build > > > > > >> something in. > > > > > >> Not my favorite (anymore) either, since apparently it's a common > > > > > use-case > > > > > >> that we would break. > > > > > >> > > > > > > Just my 2cts but sounds the worse. > > > > > > Even if going major backward compat is key for not internals > > > otherwise > > > > we > > > > > > do another build tool and break everyone which is always a moment > > of > > > > > > temptation to reject the tool, in particular when trivial to > avoid > > > from > > > > > > user PoV. > > > > > > > > > > > > > > > > > >> I understand the thread might've become hard to follow, so I > hope > > > this > > > > > >> summary helps other people to join the discussion. > > > > > >> My current favorite is 4. > > > > > >> > > > > > > > > > > > > Personally, I'd say investigate alias option and if not > satistying > > > then > > > > > use > > > > > > 2. > > > > > > > > > > > > > > > > > >> Martin > > > > > >> > > > > > >> Op za 20 feb. 2021 om 17:53 schreef Romain Manni-Bucau > > > > > >> rmannibu...@gmail.com>: > > > > > >> > > > > > >>> I like the regex idea but wildcard (*) does not work well due > to > > > > common > > > > > >>> shell expansion (or it already works but it is outside of maven > > > scope > > > > > to > > > > > >> be > > > > > >>> concrete). > > > > > >>> > > > > > >>> My 2cts would be that, to be honest, I think we all lead to > have > > > > > aliases > > > > > >> in > > > > > >>> maven for potentially very long commands (there was some > threads > > > > about > > > > > >> it), > > > > > >>> CLI then just needs to enable to activate/deactivate things, > not > > to > > > > be > > > > > >>> clever and it would enable all combination without any behavior > > > > change > > > > > >> nor > > > > > >>> new option IMHO. Concretely "mvn alias:bd" would run "mvn -pl > > > foo/bar > > > > > -pl > > > > > >>> foo/dummy" for example. Thinking out loud it can be done with a > > > > plugin > > > > > >>> already so can maybe give a try if it sounds like a good idea > for > > > > > others > > > > > >>> too. > > > > > >>> > > > > > >>> Romain Manni-Bucau > > > > > >>> @rmannibucau | Blog > > > > > >>> | Old Blog > > > > > >>> | Github > > > > > >>> https://github.com/rmannibucau> | > > > > > >>> LinkedIn | Book > > > > > >>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > >>> > > > > > >>> Le sam. 20 févr. 2021 à 14:40, Falko Modler a > > > > > écrit : > > > > > >>> > > > > > >>>> Thanks for the quick reaction/answers! > > > > > >>>> > > > > > >>>> TBH, I haven't fully understood why -N cannot be used here. I > do > > > > > >>>> understand that -N reduces the reactor to one project (before > > > > project > > > > > >>>> selection via -pl can kick in). > > > > > >>>> But what if -N wouldn't be applied if -pl is present? It would > > > then > > > > > >>> become > > > > > >>>> a "secondary" option, only applying to the projects selected > or > > > > > >>> deselected > > > > > >>>> via -pl. > > > > > >>>> > > > > > >>>> However, the most flexible and fully backwards compatiple > > solution > > > > > >> would > > > > > >>>> indeed be something like -plr as suggested before. You could > > then > > > > also > > > > > >>> mix > > > > > >>>> and match -pl and -plr. > > > > > >>>> > > > > > >>>> Btw, half offtopic: I proposed [1] to add ? to -pl and in that > > > > context > > > > > >> I > > > > > >>>> also thought about wildcard support for -pl, but Robert didn't > > > like > > > > > the > > > > > >>>> idea. > > > > > >>>> I'm just thinking whether -pl foo/* might be something that > > could > > > > help > > > > > >>>> here as well, but it wouldn't be trivial to do, I suppose. > > > > > >>>> PS: -help doesn't mention ! at all. > > > > > >>>> > > > > > >>>> [1] https://issues.apache.org/jira/browse/MNG-6511 > > > > > >>>> > > > > > >>>> Cheers, > > > > > >>>> Falko > > > > > >>>> > > > > > >>>> > > > > --------------------------------------------------------------------- > > > > > >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > >>>> For additional commands, e-mail: dev-h...@maven.apache.org > > > > > >>>> > > > > > >>>> > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > >
