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