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 <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 26 févr. 2021 à 13:16, Martin Kanters <martinkant...@apache.org> 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 <martinkant...@apache.org> > 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): <alias><rec>-pl parent, submodule-a, > > > submodule-b, submodule-c</rec></alias> > > > - 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 <f.mod...@gmx.net>: > > > > > > > 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 <proj>/* > > > > >> 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 <https://twitter.com/rmannibucau> | Blog > > > > >>> <https://rmannibucau.metawerx.net/> | Old Blog > > > > >>> <http://rmannibucau.wordpress.com> | Github < > > > > >>> https://github.com/rmannibucau> | > > > > >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > > >>> < > > > > >>> > > > > >> > > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > >>> > > > > >>> Le sam. 20 févr. 2021 à 14:40, Falko Modler <f.mod...@gmx.net> 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 > > > > > > > > > > > > > >
