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
