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: - 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.
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 > >
